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Intellectual Property Rights 
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Foreword 
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Foreword 

This Technical Specification (TS) was been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN) and originally published as final draft ETSI 
ES 283 003 [4]. It was transferred to the 3rd Generation Partnership Project (3GPP) in January 2008.The contents of the 
present document are subject to continuing work within the TSG and may change following formal TSG approval. 
Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document provides the ETSI TISPAN endorsement of 3GPP TS 24.229 [1]: "3rd Generation Partnership 
Project; Technical Specification Group Core Network and Terminals; IP multimedia call control protocol based on 
Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 7)" in line with the 
requirements of TISPAN NGN. 

The present document together with the endorsed document provides the necessary SIP/SDP specifications for 
supporting TISPAN Release 2 requirements. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] 3GPP TS 24.229 (V7.9.0): "3rd Generation Paitnership Project; Technical Specification Group 

Core Network and Terminals; IP multimedia call control protocol based on Session Initiation 
Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[2] ETSI TS 183 008: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Terminating Identification 
Presentation (TIP) and Terminating Identification Restriction (TIR); Protocol specification". 

[3] ETSI TS 183 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Originating Identification 
Presentation (OIP) and Originating Identification Restriction (OIR); Protocol specification". 

[4] final draft ETSI ES 283 003 V2.5.1 (final draft): "Telecommunications and Internet converged 

Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Call Control Protocol 
based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP 
TS 24.229 [Release 7], modified]". 
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Note: The version of ETSI ES 283 003 on which the present document is based only available during the ETSI 
membershiip approval period. It is anticipated that it will be published without technical change. 



Endorsement notice 

The present document endorses 3GPP TS 24.229 (V7.9.0): "IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 (Release 7)" [1]. 

The present document shows the modifications, additions and deletions through the use of underlined and strikethrough 

text. 

For the purpose of the present document clause 1 of [1] appUes. 

For the purpose of the present document clause 3 of [1] applies except for subclauses 3.1, 3.2, which are replaced by the 
appropriate subclauses in clause 3 of the present document. 

For the purpose of the present document clause 4 of [1] applies, except for clauses 4.1, 4.2 and 4.4.4, which are replaced 
by the appropriate clauses in clause 4 of the present document. 

For the purpose of the present document clause 5 of [1] applies, except for clauses 5.1.1.1A, 5.1.1.2, 5.1.1.3, 5.1.1.4, 
5.1.1.5.1, 5.1.1.5.2, 5.1.1.5A, 5.1.1.6, 5.1.1.7, 5.1.2.1, 5.1.2A.1, 5.1.2.A2, 5.1.3.1, 5.1.6.2, 5.1.6.8.3, 5.1.6.8.4, 5.2.1, 
5.2.2, 5.2.4, 5.2.5.1, 5.2.5.2, 5.2.6.2, 5.2.6.3, 5.2.6.4, 5.2.7.2, 5.2.7.3, 5.2.8.1.1, 5.2.8.1.2, 5.2.8.1.4, 5.2.8.3, 5.2.10.1, 
5.2.10.3, 5.3.2.1, 5.3.2.1A, 5.4.1.1, 5.4.1.2, 5.4.1.2.1, 5.4.1.2.2, 5.4.1.3, 5.4.1.4, 5.4.1.5, 5.4.1.6, 5.4.1.7, 5.4.2.1.2, 
5.4.1.8, 5.4.3.2, 5.4.3.3, 5.4.6.1.2, 5.4.6.1.3, 5.4.8.2, 5.4.5. 1.2A, 5.7.1.9, 5.10.2.2, 5.10.2.3, 5.10.3.2, 5.10.3.3 and 5.10.6, 
which are replaced by the appropriate clauses in clause 5 of the present document. In addition clauses 5. 1.1. IB, 
5.1.1.2A, 5.1.1.4A, 5.1. 1.5. lA, 5.1.1.5.1B, 5.1.1.6A, 5.2.2A and 5.4.1.2A.1 are added. 

For the piupose of the present document clause 6 of [1] applies, except for clauses 6.1.1, 6.1.2 and 6.2 , which are 
replaced by the appropriate clauses in clause 6 of the present document. 

For the purpose of the present document clause 7 of [1] applies, except for clauses 7.2A.4, 7.2A.5.2.2, 7.2A.9.2, 
7. 2A. 10.3,7.6.1, 7.6.2, 7.6.3, 7.9.2, and 7.9.3, which is replaced by the appropriate clause in clause 7 of the present 

document. 

For the purpose of the present document clause 9 of [1] applies. 

For the purpose of the present document annex A of [1] applies, except for clauses A.2.1.2, A.2. 1.4.7, A2.1.4.12, 
A.2.2.4.3, A.2.2.2, , A.2.2.4.7A, A.2.2.4.8, A.2.2.4.9, A.2.2.4.11, A.2.2.4.12, A.2.2.4.13, A.2.2.14A.2.2.4.7 and A.3.2.1 
which are replaced by the appropriate clauses in annex A of the present document. 

For the purpose of the present document annex B of [1] applies, except for subclause B.2.2.1 which is replaced by the 
appropriate subclause in annex B. In addition subclause B.2A.2 is added. 

For the purpose of the present document annex C of [1] applies, except for the addition of clause C.4. 
For the purpose of the present docimient annex F of [1] is replaced with annex F of the present document. 
For the purpose of the present docimient annex G of [1] is replaced with annex G of the present document. 
For the purpose of the present document annex I of [1] applies. 

For the purpose of the present document annex J of [1] applies, except for clauses J.l and J.2 which are replaced by the 
appropriate clauses in annex J of the present document. In addition clause J.9A is added. 

For the purpose of the present document annex F of [1] applies, except for clauses F.2. 1.2.2, F.2. 1.2.4, F.4.1 and F.4.2 
which are replaced as indicated in the appropriate clauses in annex F of the present document. 

For the purpose of the present document annex F of [1] applies with the addition of clause F.4A. 



Global modifications to 3GPP TS 24.229 

The references in clause 2 of [1] should be replaced as shown in table 1. 
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Table 1 



KeTerences in oorr lo ^4.^^y [ij 


Replaced references 


[2] 3GPP TS 23.002: "Network architecture". 


ETSI ES 282 007: "Telecommunications and Internet converged 
Services and Protocols for Advanced Networking (TISPAN); IP 
Multimedia Subsystem (IMS); Functional architecture" (note 1) 


ETSI ES 282 001 : "Telecommunications and Internet converged 
Services and Protocols for Advanced Networking (TISPAN); NGN 
Functional Architecture Release 2" (note 1) 


[4A] 3GPP TS 23.107: Quality of Service (QoS) 
concept and architecture". 


(note 2) 


[4B] 3GPP TS 23.167: IP Multimedia 
Subsystem (IMS) emergency session; Stage 2". 


ETSI TS 182 009: 'Telecommunications and Internet converged 

Services and Protocols for Advanced Networking (TISPAN); NGN 
Architecture to support emergency communication from citizen to 
authority' (note 1) 


[4C] 3GPP TS 23.122: "Non-Access-Stratum 
(NAb) functions related to Mobile btation (Mb) 
in idle mode". 


(note 2) 


[5] 3GPP TS 23.218: "IP Multimedia (IM) 
Session Handling; IM call model". 


(note 2) 


[6] 3GPP TS 23.221 : "Architectural 
requirements". 


(note 2) 


[7] 3GPP TS 23.228: "IP multimedia subsystem; 
Stage 2". 


ETSI TS 182 006: "Telecommunications and Internet converged 
Services and Protocols for Advanced Networking (TISPAN); IP 
Multimedia Subsystem (IMS); Stage 2 descnption 


[8] 3GPP TS 24.141 : "Presence service using 
the IP Multimedia (IM) Core Network (CN) 
subsystem; Stage 3". 


ETSI ES 283 030: "Telecommunications and Internet converged 
Services and Protocols for Advanced Networking (TISPAN); 
Presence Service Capability; Protocol Specification [3GPP TS 24.141 
V7.0.0, modified and OMA-TS-Presence SIMPLE-V1 0, modified]" 

(note 1) 


[10] 3GPP TS 26.235: Packet switched 
conversational multimedia applications; Default 
codecs". 


ETSI TS 181 005: Telecommunications and Internet converged 
Services and Protocols for Advanced Networking (TISPAN); Services 
and Capabilities Requirements' (note 1) 


[10A] 3GPP TS 27.060: "Mobile Station (MS) 
supporting Packet Switched Services". 


(note 2) 


[1 1A] 3GPP TS 29.162: "Intenworking between 
the IM CN subsystem and IP networks". 


ETSI TS 183 021 : "Telecommunications and Internet converged 
Services and Protocols for Advanced Networking (TISPAN); NGN 
Release 1 ; Endorsement of 3GPP TS 29.162 Interworking between 
IM CN Sub-system and IP networks" (note 1) 


[11B] 3GPPTS 29.163: "Intenworking between 
the IP Multimedia (IM) Core Network (CN) 
subsystem and Circuit Switched (CS) networks". 


ETSI ES 283 027: 'Telecommunications and Internet converged 
Services and Protocols for Advanced Networking (TISPAN); 
Endorsement of the SIP-ISUP Interworking between the IP 
Multimedia (IM) Core Network (CN) subsystem and Circuit Switched 
(CS) networks [3GPP TS 29.163 (Release 7), modified]' (note 1) 


[14] 3GPP TS 29.228: "IP Multimedia (IM) 
Subsystem Cx and Dx Interfaces; Signalling 
flows and message contents". 


ETSI TS 183 033: "Telecommunications and Internet converged 
Services and Protocols for Advanced Networking (TISPAN); IP 

Multimedia; Diameter based protocol for the interfaces between the 
Call Session Control Function and the User Profile Server 
Function/Subscription Locator Function; Signalling flows and protocol 
details [3GPP TS 29.228 V6.8.0 and 3GPP TS 29.229 V6.6.0, 
modified]" (note 1 ) 


[15] 3GPP TS 29.229: "Cx and Dx Interfaces 
based on the Diameter protocol, Protocol 
details". 


ETSI TS 183 033: "Telecommunications and Internet converged 
Services and Protocols for Advanced Networking (TISPAN); IP 
Multimedia; Diameter based protocol for the interfaces between the 
Call Session Control Function and the User Profile Server 
Function/Subscription Locator Function; Signalling flows and protocol 
details [3GPP TS 29.228 V6.8.0 and 3GPP TS 29.229 V6.6.0, 
modified]" (note 1 ) 


[16] 3GPP TS 32.240: "Telecommunication 
management; Charging management; Charging 
architecture and principles". 


ETSI ES 282 010: "Telecommunications and Internet Converged 
Services and Protocols for Advanced Networking (TISPAN); Charging 
(Endorsement of 3GPP TS 32.240 Release 7, 3GPP TS 32.260 
Release 7, 3GPP TS 32.297 Release 7, 3GPP TS 32.298 Release 7 
and 3GPP TS 32.299 Release 7 modified)" (note 1) 
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References in 3GPP TS 24.229 [1] 


Replaced references 


[17] 3GPP TS 32.260: "Telecommunication 
management; Charging management; IP 
Multimedia Subsystem (IMS) charging". 


ETSI ES 282 010: "Telecommunications and Internet Converged 
Services and Protocols for Advanced Networking (TISPAN); Charging 
[Endorsement of 3GPP TS 32.240 Release 7, 3GPP TS 32.260 
Release 7, 3GPP TS 32.297 Release 7, 3GPP TS 32.298 Release 7 
and 3GPP TS 32.299 Release 7modified]" (note 1) 


[19] 3GPP TS 33.203: "Access security for IP 

based services". 


(note 2) 


[67] draft-rosenberg-sipping-acr-code-00 
(November 2005): "Rejecting Anonymous 
Requests In the Session Initiation Protocol 
(SIP)". 


IETF RFC 5079 (December 2007): "Rejecting Anonymous Requests 
in the Session Initiation Protocol (SIP)". 


[68] draft-jennings-sip-voicemail-uri-05 
(November 2005): "Session Initiation Protocol 
(SIP) URIs for Applications such as Voicemail 
and Interactive Voice Response (IvR) . 


IETF RFC 4458: "Session Initiation Protocol (SIP) URIs for 
Applications such as Voicemail and interactive Voice Response 
(IVR)" (note 1) 


[69] draft-ietf-ecrit-service-urn-06 
(March 2007): "A Uniform Resource Name 
(URN) for Services". 


[69] RFC 5031 (January 2008): "A Uniform Resource Name (URN) 
for Services". 


[79] draft-ietf-rohc-sigcomp-sip-07 (July 2007): 
"Applying Signaling Compression (SIgComp) to 
the Session Initiation Protocol (SIP)". 


RFC 5049 (December 2007): "Applying Signaling Compression 
(SigComp) to the Session Initiation Protocol (SIP)". 


[85] 3GPP2 C.S0005-D (March 2004): "Upper 
Layer (Layer 3) Signalling Standard for 
cdma2000 Standards for Spread Spectrum 

Systems". 


(note 2) 


[86] 3GPP2 C.S0024-A v1 .0 (April 2004): 
"cdma2000 High Rate Packet Data Air Interface 
Standard". 


(note 2) 


[87] ITU-T Recommendation J. 11 2, 
"Transmission Systems for Interactive Cable 
Television Services" 


(note 2) 


[88] PacketCable Release 2 Technical Report, 
PacketCable™ Architecture Framework 
Technical Report, PKT-TR-ARCH-FRM. 


(note 2) 


[89] draft-ietf-sip-location-conveyance-08 
(July 2007): "Session Initiation Protocol Location 
Conveyance". 


[89] draft-ietf-sip-location-conveyance-10 (February 2008): 
"Location Conveyance for the Session Initiation Protocol". 


[91 ] draft-ietf-ecrit-requirements-1 3 
(March 2007): "Requirements for Emergency 
Context Resolution with Internet Technologies". 


[91] RFC 5012 (January 2008): "Requirements for Emergency 
Context Resolution with Internet Technologies". 


[93] draft-ietf-sip-gruu-14 (June 2007): 
"Obtaining and Using Globally Routable User 
Agent (UA) URIs (GRUU) in the Session 
Initiation Protocol (SIP) . 


draft-ietf-sip-gruu-15 (October 2007): "Obtaining and Using Globally 
Routable User Agent (UA) URIs (GRUU) in the Session Initiation 
Protocol (SIP)". 


[94] draft-ietf-sipping-gruu-reg-event-08 
(October 2006): "Reg Event Package Extension 
forGRUUs". 


[94] draft-ietf-sipping-gruu-reg-event-09 (July 2007): "Reg Event 
Package Extension for GRUUs". 


[97] draft-camarillo-sipping-profile-key-02 
(June 2007): "The Session Initiation Protocol 
(SIP) P-Profile-Key Private Header (P-Header)". 


RFC 5002 (August 2007): "The Session Initiation Protocol (SIP) P- 
Profile-Key Private Header (P-Header)". 


[1 09] draft-ejzak-sipping-p-em-auth-04.txt 
(June 2007): "Private Header (P-Header) 
Extension to the Session Initiation Protocol 
(SIP) for Authorization of Early Media". 


[109] RFC 5009 (September 2007): "Private Header (P-Header) 
Extension to the Session Initiation Protocol (SIP) for Authorization of 
Early Media". 


[Ill] draft-allen-sipping-poc-p-answer-state- 
header-05 (March 2007): "The P-Answer-State 
Header Extension to the Session Initiation 
Protocol for the Open Mobile Alliance Push to 
talk over Cellular". 


RFC 4964 (September 2007): "The P-Answer-State Header 
Extension to the Session Initiation Protocol for the Open Mobile 

A II" r-\ 1 ■ II y"^ II 1 II 

Alliance Push to Talk over Cellular . 


[119] draft-garcia-simple-presence-dictionary-06 
(August 2007): "The Presence-Specific Static 
Dictionary for Signaling Compression 
(Sigcomp)". 


RFC 51 12 (January 2008): "The Presence-Specific Static Dictionary 
for Signaling Compression (Sigcomp)". 
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References in 3GPP TS 24.229 [1] Replaced references 



NOTE 1 : The reference in [1 ] is replaced by the document listed on the right column. This replacement is applicable 

to all occurrences of the reference throughout the present endorsement. 
NOTE 2: The reference in [1] contains 3GPP or 3GPP2 or cable specific requirements and is not generally applicable 
to the present endorsement. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

Entry point: In the case that "border control concepts", as specified in 3GPP TS 23.228 [7], are to be applied in 
an IM CN subsystem, then these are to be provided by capabilities within the IBCF, and the IBCF 
acts as an entry point for this network (instead of the I-CSCF). In this case the IBCF and the I- 
CSCF can be co-located as a single physical node. If "border control concepts" are not appUed, 
then the I-CSCF is considered as an entry point of a network. If the P-CSCF is in the home 
network, then the I-CSCF is considered as an entry point for this document. 

Exit point: If operator preference requires the application of "border control concepts" as specified in 

3GPP TS 23.228 [7], then these are to be provided by capabilities within the IBCF, and requests 
sent towards another network are routed via a local network exit point (IBCF), which will then 
forward the request to the other network (discovering the entry point if necessary). 

Geo-Iocal number: Either a geo-local service number as specified in 3GPP TS 23.228 [7] or a number in non- 
international format according to an addressing plan used at the current physical location of the 
user. 

Home-local number: Either a home local service number as specified in 3GPP TS 23.228 [7] or a number in non- 
international format according to an addressing plan used in the home network of the user. 

Newly established set of security associations: Two pairs of IPsec security associations that have been created at 
the UE and/or the P-CSCF after the 200 (OK) response to a REGISTER request was received. 

Old set of security associations: Two pairs of IPsec security associations still in existence after another set of 
security associations has been established due to a successful authentication procedure. 

Temporary set of security associations: Two pairs of IPsec security associations that have been created at the UE 

and/or the P-CSCF, after an authentication challenge within a 401 (Unauthorized) response to a 
REGISTER request was received. The SIP level lifetime of such created security associations will 
be equal to the value of reg-await-auth timer. 

Integrity protected: See 3GPP TS 33.203 [19]. Where a requirement exists to send information "integrity 

protected" the mechanisms specified in 3GPP TS 33.203 [19] are used for sending the information. 
Where a requirement exists to check that information was received "integrity protected", then the 
information received is checked for compUance with the procedures as specified in 
3GPPTS 33.203 [19]. 

Instance ID: An URN generated by the device that uniquely identifies a specific device amongst all other 

devices, and does not contain any information pertaining to the user (e.g., in GPRS instance ID 
applies to the Mobile Equipment rather than the UICC). The public user identity together with the 
instance ID uniquely identifies a specific UA instance. 

Resource reservation: Mechanism for reserving bearer resources that is required for certain access technologies. 

Local preconditions: The indication of segmented status preconditions for the local reservation of resources as 
specified in RFC 3312 [30]. 

Alias SIP URI: A URI is an alias of another URI if the treatment of both URIs is identical, i.e. both URIs belong 
to the same set of imphcitly registered public user identities, and are linked to the same service 
profile, and are considered to have the exact same service configuration for each and every service. 



ETSI 



Release 7 



11 



ETSI TS 124 503 V8.6.0 (2009-09) 



Initial registration: The registration procedure for a public user identity initiated by the UE in the absence of any 
vaUd registration. 

Re-registration: The registration procedure initiated by the UE to refresh or update an already existing registration 
for a public user identity. 

Registration of an additional public user identity: The registration procedure initiated by the UE to explicitly 
register an additional public user identity during the life time of the registration of another 
registered public user identity, where both public user identities have the same contact address and 
P-CSCF. 

Emergency registration: A special registration that relates to an emergency public user identity. 

Initial emergency registration: An emergency registration that is also an initial registration. 

Emergency reregistration: An emergency registration that is also a reregistration. 

Back-to-Back User Agent (B2BUA): As given in RFC 3261 [26]. In addition, for the usage in the IM CN 

subsystem, a SIP element being able to handle a collection of "n" User Agents (behaving each one 
as UAC and UAS, according to SIP rules), which are linked by some appUcation logic that is fuUy 
independent of the SIP rules. 

UE private IP address: It is assumed that the NAT device performs network address translation between a private 
and a public network with the UE located in the private network and the IM CN subsystem in the 
public network. The UE is assumed to be configured with a private IP address. This address will 
be denoted as UE private IP address. 

UE public IP address: The NAT device is assumed to be configured with one (or perhaps more) public 

address(es). When the UE sends a request towards the public network, the NAT replaces the 
source address in the IP header of the packet, which contains the UE private IP address, with a 
public IP addressed assigned to the NAT. This address will be denoted as UE pubUc IP address. 

Encapsulating UDP header: For the purpose of performing UDP encapsulation according to RFC 3948 [63A] 
each IPsec ESP packet is wrapped into an additional UDP header. This header is denoted as 
Encapsulating UDP header. 

Port_Uenc: In most residential scenarios, when the NAT device performs address translation, it also performs 
translation of the source port found in the transport layer (TCP/UDP) headers. Following 
RFC 3948 [63A], the UE will use port 4500 as source port in the encapsulating UDP header when 
sending a packet. This port is translated by the NAT into an arbitrarily chosen port number which 
is denoted as port_Uenc. 

IMS flow set: An IMS flow set is a set of four flows as defined in draft-ietf-outbound [92]. The flows in an IMS 
flow set are determined by a combination of transport protocol, IP addresses, protected client ports 
and protected server ports as defined in 3GPP TS 33.203 [19]. An IMS flow set is established by a 
successful IMS registration procedure. 

NOTE 1 : . The four flows in an IMS flow set are set up as follows: 

- Flow 1 : (IP address UE, port_uc) <-> (IP address P-CSCF, port_ps) over TCP; 

- Flow 2: (IP address UE, port_uc) <--> (IP address P-CSCF, port_ps) over UDP; 

- Flow 3: (IP address UE, port_us) <-> (IP address P-CSCF, port_pc) over TCP; and 

- Flow 4: (IP address UE, port_us) <-> (IP address P-CSCF, port_pc) over UDP. 

NOTE 2: According to 3GPP TS 33.203 [19], the P-CSCF can only select among flows 1, 3, or 4 when forwarding 
requests towards the UE, where flow 1 is only possible in case of TCP connection re-use. According to 
3GPP TS 33.203 [19], flow 2 is only used for UE originated requests and corresponding responses. The 
P-CSCF uses flow 2 to identify the correct IMS flow set. 

NOTE 3: An IMS flow set can be considered as a realisation of a logical flow as used in draft-ietf-sip- 

outbound [92]. But this deflnition does not depend on any particular definition of a logical flow. 
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IMS flow token: A IMS flow token is uniquely associated with a IMS flow set. When forwarding a request destined 
towards the UE, the P-CSCF selects the flow from the IMS flow set denoted by the IMS flow 
token as appropriate according to 3GPP TS 33.203 [19] and RFC 3261 [26]. 

Network-initiated resource reservation; A mechanism of resource reservation where the IP-CAN on the behalf of 
network initiates the resources to the UE 



For the purposes of the present document, the following terms and definitions given in RFC 1594 [20B] apply. 

FuUy-QuaUfled Domain Name (FQDN) 

For the purposes of the present document, the following terms and definitions given in RFC 3261 [26] apply (unless 
otherwise specified see clause 6). 

Client 
Dialog 

Final response 
Header 
Header field 
Loose routeing 
Method 

Option-tag (see RFC 3261 [26] subclause 19.2) 

Provisional response 

Proxy, proxy server 

Recursion 

Redirect server 

Registrar 

Request 

Response 

Server 

Session 

(SIP) transaction 
Stateful proxy 
Stateless proxy 

Status-code (see RFC 3261 [26] subclause 7.2) 
Tag (see RFC 3261 [26] subclause 19.3) 
Target Refresh Request 
User agent client (UAC) 
User agent server (UAS) 
User agent (UA) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.002 [2] 
subclause 4.1.1.1 and subclause 4a.7 apply: 

Breakout Gateway Control Function (BGCF) 

Call Session Control Function (CSCF) 

Home Subscriber Server (HSS) 

Media Gateway Control Function (MGCF) 

Multimedia Resource Function Controller (MRFC) 

Multimedia Resource Function Processor (MRFP) 

Subscription Locator Function (SLF) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.122 [4C] apply: 

Home PLMN (HPLMN) 
Visited PLMN (VPLMN) 



For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.218 [5] 
subclause 3.1 apply: 

Filter criteria 
Initial filter criteria 
Initial request 
Standalone transaction 
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Subsequent request 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [7] 
subclauses 3.1, 4.3.3.1, 4.3.6, 4.6, 4.13, 5.2, 5.4.12.1 and 5.10 apply: 

Border control concepts 
Geo-local service number 
Home local service number 
Implicit registration set 

Interconnection Border Control Function (IBCF) 

Interrogating-CSCF (I-CSCF) 

IMS Application Level Gateway (IMS-ALG) 

EMS application reference 

IMS application reference identifier (lARI) 

IMS communication service 

EMS Ccommunication Sservice lidentifler (ICSI) 

IMS communication s e rvic e id e ntifi e r 

Local service number 

IP-Connectivity Access Network (IP-CAN) 

Policy and Charging Rule Function (PCRF) 

Private user identity 

Proxy-CSCF (P-CSCF) 

Public Service Identity (PSI) 

Public user identity 

Serving-CSCF (S-CSCF) 

Statically pre-configured PSI 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.167 [4B]apply: 

Emergency-CSCF (E-CSCF) 
Geographical location information 
Location identifier 
Location information 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 33.203 [19] apply: 

EM Subscriber Identity Module (ISEM) 

Port_pc 

Port_ps 

Port_uc 

Port_us 

Protected server port 
Protected client port 

For the purposes of the present document, the following terms and definitions given in 3 GPP TR 21.905 [1] apply: 

Universal Integrated Circuit Card (UICC) 
Universal Subscriber Identity Module (USEM) 
User Equipment (UE) 

For the piuposes of the present document, the following terms and definitions given in RFC 2401 [20A] Appendix A 
apply: 

Security association 

A number of different security associations exist within the IM CN subsystem and within the underlying access 
transport. Within this document this term specifically applies to either: 

i) the security association that exists between the UE and the P-CSCF. This is the only security association that has 
direct impact on SIP; or 

ii) the security association that exists between the WLAN UE and the PDG. This is the security association that is 
relevant to the discussion of Interworking WLAN as the underlying IP-CAN. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.002 [IB] apply: 
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WLAN UE 

3GPP AAA proxy 

3GPP AAA server 

Packet Data Gateway (PDG) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.234 [7 A] apply. 

Interworking WLAN 

For the purposes of the present document, the following terms and definitions given in ITU-T E.164 [57] apply: 

International public telecommunication number 

For the purposes of the present document, the following terms and definitions given in draft- ietf-ecrit-requirements [91] 
apply: 

Emergency service identifier 
Emergency service URN 
Public Safety Answering Point (PSAP) 
PSAP URI 

For the purposes of the present document, the following terms and definitions given in draft-ietf-sip-gruu [93] apply: 

Globally Routable User Agent URI (GRUU) 

For the purposes of the present document, the following terms and definitions given in draft-ietf-sip-outbound [92] 
apply: 



Flow 



3.2 



Abbreviations 



For the purposes of the 



present document, the following abbreviations apply: 



BRAS 

CCF 

CDF 

CDR 

CK 

CN 

CPC 

CSCF 

DHCP 

DNS 

DOCSIS 

DTD 

EC 

ECF 

E-CSCF 

FQDN 

GCID 

GGSN 

GPRS 

GRUU 

HPLMN 



Ixx 

2xx 

AAA 

AS 

APN 



AUTN 

B2BUA 

BGCF 



c 



A status-code in the range 101 through 199, and excluding 100 

A status-code in the range 200 through 299 

Authentication, Authorization and Accounting 

Application Server 

Access Point Name 

Authentication TokeN 

Back- to -Back User Agent 

Breakout Gateway Control Function 

conditional 

Broadband Remote Access Server 

Charging Collection Function 

Charging Data Function 

Charging Data Record 

Ciphering Key 

Core Network 

Calling Party Category 

Call Session Control Function 

Dynamic Host Configuration Protocol 

Domain Name System 

Data Over Cable Service Interface Specification 

Document Type Definition 

Emergency Centre 

Event Charging Function 

Emergency CSCF 

Fully Qualified Domain Name 

GPRS Charging Identifier 

Gateway GPRS Support Node 

General Packet Radio Service 

Globally Routable User agent URI 

Home PLMN 
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HSS 


Home Subscriber Server 


i 


irrelevant 


lARI 


IMS Application Reference Identifier 


IBCF 


Interconnection Border Control Function 


I-CSCF 


Interrogating CSCF 


ICID 


IM CN subsystem Charging Identifier 


ICSI 


IMS Communication Service Identifier 


IK 


Ttitepritv TCev 


IM 


IP Multimedia 


IMS 


IP Multimedia core network Subsystem 


IMS-ALG 


IMS Annlication T£ve1 Gatewav 


IMSI 


International Mobile Subscriber Identity 


lOI 


Inter Operator Identifier 


IP 


Internet Protocol 


IP-CAN 


IP-Connectivity Access Network 


IPsec 


IP security 


IPv4 


Internet Protocol version 4 


IPv6 


Internet Protocol version 6 


ISC 


TP IVTultimedia Subsvsteni Service Control 


ISIM 


IM Subscriber Identity Module 


IWF 


Interworking Function 


I-WLAN 


Interworking — WLAN 


LRF 


Location Retrieval Function 


m 


mandatory 


MAC 


Message Authentication Code 


MCC 


Mobile Country Code 


MGCF 


Media Gateway Control Function 


MOW 


Media Gateway 


MNC 


Mobile Network Code 


MRFC 


Multimedia Resource Function Controller 


MRFP 


Multimedia Resource Function Processor 


n/ti 


not annlicable 


NAI 


Network Access Identifier 


NA(P)T 


Network Address (and Port) Translation 


NASS 


Network Attachement Subsystem 


NAT 


Network Address Translation 





optional 


OCF 


Online Charging Function 


PCRF 


Policy and Charging Rules Function 


P-CSCF 


Proxy CSCF 


PDG 


Packet Data Gateway 


PDP 


Packet Data Protocol 


PDU 


Protocol Data Unit 


PIDF-LO 


Presence Information Data Format Location Object 


PLMN 


Public Land Mobile Network 


PSAP 


Public Safety Answering Point 


PSI 


Public Service Identity 


PSTN 


Public Switched Telephone Network 


QoS 


Quahty of Service 


RAND 


RANDom challenge 


RES 


RESponse 


RTCP 


Real-time Transport Control Protocol 


RTP 


Real-time Transport Protocol 


S-CCF 


Servine CSCF 


SCTP 


Stream Control Transmission Protocol 


SDP 


Session Description Protocol 


SIP 


Session Initiation Protocol 


SLF 


Subscription Locator Function 


SQN 


SeQuence Number 


UA 


User Agent 


UAC 


User Agent Client 


UAS 


User Agent Server 
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UE 


User Equipment 


UICC 


Universal Integrated Circuit Card 


URI 


Uniform Resource Identifier 


URL 


Uniform Resource Locator 


URN 


Uniform Resource Name 


UDVM 


Universal Decompressor Virtual Machine 


UPSF 


User Profile Server Function 


USIM 


Universal Subscriber Identity Module 


VPLMN 


Visited PLMN 


WLAN 


Wireless Local Area Network 


X 


prohibited 


xDSL 


Digital Subscriber Line (all types) 


XMAC 


expected MAC 


XML 


extensible Markup Language 



4 General 

4.1 Conformance of IM CN subsystem entities to SIP, SDP and other protocols 

SIP defines a number of roles which entities can implement in order to support capabilities. These roles are defined in 
annex A. 

Each IM CN subsystem functional entity using an interface at the Gm reference point, the Ma reference point, the Mg 
reference point, the Mi reference point, the Mj reference point, the Mk reference point, the Mm reference point, the Mr 
reference point and the Mw reference point, and also using the IP multimedia Subsystem Service Control (ISC) 
Interface, shall implement SIP, as defined by the referenced specifications in annex A, and in accordance with the 
constraints and provisions specified in annex A, according to the following roles. 

The Gm reference point, the Ma reference point, the Mg reference point, the Mi reference point, the Mj reference point, 
the Mk reference point, the Mm reference point, the Mr reference point, the Mw reference point and the ISC reference 
point are defined in 3GPP TS 23.002 [2]. 

The User Equipment (UE) shall provide the User Agent (UA) role, with the exceptions and additional 
capabiUties to SIP as described in subclause 5.1, with the exceptions and additional capabilities to SDP as 
described in subclause 6.1, and with the exceptions and additional capabilities to SigComp as described in 
subclause 8.1. The UE shall also provide the access dependent technologv specific procedures described in the 
appropriate access technology specific annex (see subclause 3A and subclause 9.2.2) subclause B.2.2 . 

The P-CSCF shall provide the proxy role, with the exceptions and additional capabilities to SIP as described in 
subclause 5.2, with the exceptions and additional capabilities to SDP as described in subclause 6.2, and with the 
exceptions and additional capabilities to SigComp as described in subclause 8.2. Under certain circumstances as 
described in subclause 5.2, the P-CSCF shall provide the UA role with the additional capabilities, as follows: 

a) when acting as a subscriber to or the recipient of event information; and 

b) when performing P-CSCF initiated dialog-release, even when acting as a proxy for the remainder of the 
dialog. 

The P-CSCF shall also provide the access technologv specific procedures described in the appropriate access 
technologv specific annex (see subclause 3A and subclause 9.2.2). 

- The 1-CSCF shall provide the proxy role, with the exceptions and additional capabilities as described in 
subclause 5.3. 

- The S-CCF shall provide the proxy role, with the exceptions and additional capabilities as described in 
subclause 5.4, and with the exceptions and additional capabilities to SDP as described in subclause 6.3. Under 
certain circumstances as described in subclause 5.4, the S-CCF shall provide the UA role with the additional 
capabilities, as follows: 

a) the S-CCF shall also act as a registrar. When acting as a registrar, or for the purposes of executing a third- 
party registration, the S-CCF shall provide the UA role; 

b) as the notifier of event information the S-CCF shall provide the UA role; 
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c) when providing a messaging mechanism by sending the MESSAGE method, the S-CCF shall provide the UA 
role; and 

d) when performing S-CCF initiated dialog release the S-CCF shall provide the UA role, even when acting as a 
proxy for the remainder of the dialog. 

- The MGCF shall provide the UA role, with the exceptions and additional capabiUties as described in 
subclause 5.5, and with the exceptions and additional capabilities to SDP as described in subclause 6.4. 

- The BGCF shall provide the proxy role, with the exceptions and additional capabiUties as described in 
subclause 5.6. 

The AS, acting as terminating UA, or redirect server (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.1), shall 
provide the UA role, with the exceptions and additional capabiUties as described in subclause 5.7.2, and with the 
exceptions and additional capabiUties to SDP as described in subclause 6.6. 

- The AS, acting as originating UA (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.2), shaU provide the UA 
role, with the exceptions and additional capabilities as described in subclause 5.7.3, and with the exceptions and 
additional capabiUties to SDP as described in subclause 6.6. 

The AS, acting as a SIP proxy (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.3), shaU provided the proxy 
role, with the exceptions and additional capabilities as described in subclause 5.7.4. 

- The AS, performing 3rd party call control (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.4), shall provide 
the UA role, with the exceptions and additional capabilities as described in subclause 5.7.5, and with the 
exceptions and additional capabiUties to SDP as described in subclause 6.6. 

NOTE 1: Subclause 5.7 and its subclauses define only the requirements on the AS that relate to SIP. Other 
requirements are defined in 3GPP TS 23.218 [5]. 

- The AS, receiving third-party registration requests, shall provide the UA role, with the exceptions and additional 
capabilities as described in subclause 5.7. 

- The MRFC shall provide the UA role, with the exceptions and additional capabilities as described in 
subclause 5.8, and with the exceptions and additional capabilities to SDP as described in subclause 6.5. 

- The IBCF shall provide the proxy role, with the exceptions and additional capabilities to SIP as described in 
subclause 5.10, and with the exceptions and additional capabilities to SDP as described in subclause 6.6. If the 
IBCF provides an application level gateway functionality, then the IBCF shall provide the UA role, with the 
exceptions and additional capabiUties to SIP as described in subclause 5.10, and with the exceptions and 
additional capabilities to SDP as described in subclause 6.6. If the IBCF provides screening functionality, then 
the IBCF may provide the UA role, with the exceptions and additional capabilities to SIP as described in 
subclause 5.10. 

- The E-CSCF shall provide the proxy role, with the exceptions and additional capabiUties as described in 
subclause 5.11. 

In addition to the roles specified above, the P-CSCF, the 1-CSCF, the S-CCF, the BGCF and the E-CSCF can act as a 
UA when providing server functionality to return a final response for any of the reasons specified in RFC 3261 [26]. 

NOTE 2: Annex A can change the status of requirements in referenced specifications. Particular attention is drawn 
to table A.4 and table A.162 for capabilities within referenced SIP specifications, and to table A.317 and 
table A. 328 for capabilities within referenced SDP specifications. The remaining tables build on these 
initial tables. 

NOTE 3: The allocated roles defined in this clause are the starting point of the requirements from the IETF SIP 
specifications, and are then the basis for the description of further requirements. Some of these extra 
requirements formally change the proxy role into a B2BUA. In all other respects other than those more 
completely described in subclause 5.2 the P-CSCF implements proxy requirements. Despite being a 
B2BUA a P-CSCF does not implement UA requirements from the IETF RFCs, except as indicated in this 
specification, e.g., relating to registration event subscription. 
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NOTE 4: Except as specified in clause 5 or otherwise permitted in RFC 3261, the functional entities providing the 
proxy role are intended to be transparent to data within received requests and responses. Therefore these 
entities do not modify message bodies. If local policy applies to restrict such data being passed on, the 
functional entity has to assume the UA role and reject a request, or if in a response and where such 
procedures apply, to pass the response on and then clear the session using the BYE method. 

All the above entities are functional entities that could be implemented in a number of different physical platforms 
coexisting with a number of other functional entities. The implementation shall give priority to transactions at one 
functional entity, e.g. that of the E-CSCF, over non-emergency transactions at other entities on the same physical 
implementation. Such priority is similar to the priority within the functional entities themselves specified elsewhere in 
this document. 

Additional routeing functionality can be provided to support the ability for the IM CN subsystem to provide transit 
functionality as specified in annex I. The additional routeing functionality shall assume the proxy role. 

4.2 URI and address assignments 

In order for SIP and SDP to operate, the following prerequisite conditions apply: 

1) I-CSCFs used in registration are allocated SIP URIs. Other IM CN subsystem entities may be allocated SIP 
URIs. For example sip:pcscf.homel.net and sip:<impl-specific-info>@pcscf.homel.net are valid SIP URIs. If 
the user part exists, it is an essential part of the address and shall not be omitted when copying or moving the 
address. How these addresses are assigned to the logical entities is up to the network operator. For example, a 
single SIP URI may be assigned to all I-CSCFs, and the load shared between various physical boxes by 
underlying IP capabilities, or separate SIP URIs may be assigned to each I-CSCF, and the load shared between 
various physical boxes using DNS SRV capabilities. 

2) All IM CN subsystem entities are allocated IP addresses. For systems providing access to IMS using a fixed 
broadband network, any IM CN Subsystem entities can be allocated IPv4 only, IPv6 only or both IPv4 and IPv6 
addresses. Otherwise, systems shall support IP addresses as specified in 3GPP TS 23.221 [6] subclause 5.1. 

3) The subscriber is allocated a private user identity by the home network operator, and this is contained within the 
ISIM application, if present. Where no ISIM appUcation is present but USIM is present, the private user identity 
is derived (see subclause 5. 1.1.1 A). This private user identity is available to the SIP application within the UE. 
For UEs, where neither ISIM application nor USIM are present, the private user identity is available to the UE 
via other means (see subclause 5. 1.1. IB). 

NOTE 1: The SIP URIs can be resolved by using any of public DNSs, private DNSs, or peer-to-peer agreements. 

4) The subscriber is allocated one or more public user identities by the home network operator. The public user 
identity shall take the form of SIP URI as specified in RFC 3261 [26] or tel URI as specified in RFC 3966 [22]. 
At least one of the public user identities is a SIP URI and it is stored within the ISIM application, if ISIM 
application is present. Where no ISIM application is present but USIM is present, the UE derives a temporary 
public user identity (see subclause 5.1.1.1A). All registered public user identities are available to the SIP 
application within the UE, after registration. 

5) If the UE supports GRUU (see table A.4, item A.4/53), then it shall have an Instance ID, in conformance with 
the mandatory requirements for Instance IDs specified in draft-ietf-sip-gruu [93] and draft-ietf-sip- 
outbound [92]. 

6) For each tel URI, there is at least one alias SIP URI in the set of implicitly registered pubhc user identities that is 
used to implicitly register the associated tel URI. 

7) The public user identities may be shared across multiple UEs. A particular public user identity may be 
simultaneously registered from multiple UEs that use different private user identities and different contact 
addresses. When reregistering and deregistering a given public user identity and associated contact address, the 
UE will use the same private user identity that it had used during the initial registration of the respective public 
user identity and associated contact address. If the tel URI is a shared public user identity, then the associated 
alias SIP URI is also a shared public user identity. Likewise, if the alias SIP URI is a shared public user identity, 
then the associated tel URI is also a shared public user identity. 
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8) For the purpose of access to the IM CN subsystem, UEs are assigned IPv6 prefixes in accordance with the 
constraints specified in 3GPP TS 23.221 [6] subclause 5.1 (see subclause 9.2.1 for the assignment procedures). 
In the particular case of UEs accessing the IMS using a fixed broadband intercormection, UEs can be allocated 
IPv4 only, IPv6 only or both IPv4 and IPv6 addresses. 

9) For the purpose of emergency service, the UE shall use at least an emergency public user identity, which is a SIP 
URl derived as specified in 3GPP TS 23.003 [3] and an associated tel URL 

10) For the purpose of indicating an IMS communication service to the network, UEs are assigned IMS 
communication service identifier ( ICS I) values appropriate to the IMS communicalion services supported by tlie 
UE, coded as URN as specified in subclause 7.2A.8.2. An ICSl identifies a service, e.g. media and service 
characteristics, and is used by the S CSCF and third party AS for the piuposes of authorisation and providing 
service procedures. The UE can send and receive ICSI values in SIP signalling to indicate the related IMS 
communication service. 

4.2A Transport mechanisms 

This document makes no requirement on the transport protocol used to transfer signalling information over and above 
that specified in RFC 3261 [26] clause 18. However, the UE and IM CN subsystem entities shall transport SIP messages 
longer than 1 300 bytes according to the procedures of RFC 326 1 [26] subclause 18.1.1, even if a mechanism exists of 
discovering a maximum transmission unit size longer than 1500 bytes. 

NOTE 1: Support of SCTP as specified in RFC 4168 [96] is optional for IM CN subsystem entities implementing 
the role of a UA or proxy. SCTP transport between the UE and P-CSCF is not supported in the present 
document. Support of the SCTP transport is currently not described in 3GPP TS 33.203 [19]. 

For initial REGISTER requests, the UE and the P-CSCF shall apply port handling according to subclause 5.1.1.2 (or 
subclause 5.1.1 .2A) and subclause 5.2.2 (or subclause 5.2.2A) . 

When a security association is used to access the IM CN subsystem, the UE and the P-CSCF shall send and receive 
request and responses other than initial REGISTER requests on the protected ports as described in 
3GPP TS 33.203 [19]. For UEs loaded with a ISIM or USIM, the security association shall always be used to access the 
IM CN subsystem as described in 3GPP TS 33.203 [19]. 

NOTE 2: The usage of NASS-bundled authentication, which provides for the user authentication without creation 
of a security association, still requires convergence with equivalent 3GPP documents, along with ensuring 
interoperability and coexistence with other security mechanisms. This will be addressed in a future 
version of this document, and may introduce some revision of the procedures. 

In case of an emergency session if the UE does not have sufficient credentials to authenticate with the IM CN 
subsystem and regulations allow, the UE and P-CSCF shall send request and responses other than initial REGISTER 
requests on non protected ports. 

4.4.4 History-Info 

A functional entity at the boundary of the trust domain will need to determine whether to remove the History-Info 
header according to RFC 4244 [6634] subclause 3.3 when SIP signalling crosses the boundary of the trust domain. 
Subclause 5.4 identifies additional cases for the removal of the History-Info header. 

5 Application usage of SIP 

5.1 .1 .1 A Parameters contained in the ISIM 

This subclause applies when a UE contains either an ISIM or a USIM. 

The ISIM application shall always be used for IMS authentication, if it is present, as described in 3GPP TS 33.203 [19]. 

The ISIM is preconfigured with all the necessary parameters to initiate the registration to the IM CN subsystem. These 
parameters include: 

- the private user identity; 

- one or more pubUc user identities; and 
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- the home network domain name used to address the SIP REGISTER request 

In case the UE is loaded with a UICC that does not contain the ISIM appUcation, the UE shall: 

- generate a private user identity; 

- generate a temporary public user identity; and 

- generate a home network domain name to address the SIP REGISTER request to; 
in accordance with the procedures in clause C.2. 

The temporary public user identity is only used in REGISTER requests, i.e. initial registration, re-registration, UE- 
initiated deregistration. The UE shall not reveal to the user the temporary pubHc user identity if the temporary pubhc 
user identity is barred. The temporary pubUc user identity is not barred if received by the UE in the P-Associated-URI 
header. 

If the UE is unable to derive the parameters in this subclause for any reason, then the UE shall not proceed with the 
request associated with the use of these parameters and will not be able to register to the IM CN subsystem. 

5.1.1.1B Parameters provisioned to a UE without ISIM or USIM 

In case the UE contains neither a ISlM application nor a USIM, the parameters used by the UE to initiate the 
registration to the IM CN subsystem and for authentication shall be preconfigured in accordance with clause C.4. 

5.1 .1 .2 Initial registration (with security association setup) 

The initial registration procedure consists of the UE sending an unprotected initial REGISTER request and, upon being 
challenged, sending the integrity protected REGISTER request. The UE can register a public user identity with its 
contact address at any time after it has acquired an IP address, discovered a P-CSCF, and established an IP-CAN bearer 
that can be used for SIP signalling. However, the UE shall only initiate a new registration procedure when it has 
received a final response from the registrar for the ongoing registration, or the previous REGISTER request has timed 
out. 

The UE shall send only the initial REGISTER requests to the port advertised to the UE during the P-CSCF discovery 
procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, the UE 
shall send the initial REGISTER request to the SIP default port values as specified in RFC 3261 [26]. 

The UE shall extract or derive a public user identity, the private user identity, and the domain name to be used in the 
Request- URI in the registration, according to the procedures described in subclause 5. 1.1.1 A. A pubhc user identity 
may be input by the end user. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 

a) an Authorization header, with: 

the usemame field, set to the value of the private user identity; 

- the realm directive, set to the domain name of the home network; 

- the uri directive, set to the SIP URI of the domain name of the home network; 

- the nonce directive, set to an empty value; and 

- the response directive, set to an empty value; 

b) a From header set to the SIP URI that contains the public user identity to be registered; 

c) a To header set to the SIP URI that contains the public user identity to be registered; 

d) a Contact header set to include SIP URI(s) containing the IP address of the UE in the hostport parameter or 
FQDN. If the UE supports GRUU (see table A.4, item A.4/53), it shall include a +sip.instance parameter 
containing the instance ID. The UE shall include all supported ICSl values (coded as specified in 

subclause 7.2A.8.2) in a g.3gpp.icsi-ref feature tag as defined in subclause 7.9.2 and RFC 3840 [621 for the IMS 
communication services it intends to use , and lARI values (coded as specified in subclause 7.2A.9.2), for the 
IMS communication services and IMS applications it intends to use in a g.3gpp.iari-ref feature tag as defined in 
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subclause 7.9.3 sip.app subtype feature tag according to draft rosenberg sip app media tag [120] and 

RFC 3840 [62]. If the REGISTER request is protected by a security association, the UE shall also include the 

protected server port value in the hostport parameter; 

e) a Via header set to include the IP address or FQDN of the UE in the sent-by field. For the UDP, if the 
REGISTER request is protected by a security association, the UE shall also include the protected server port 
value in the sent-by field, while for the TCP, the response is received on the TCP connection on which the 
request was sent; 

NOTE 1 : If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 

Via header, then it has to ensure that the given FQDN wiU resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 

NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security 
association. For details on the selection of the port values see 3GPP TS 33.203 [19]. 

f) an Expires header, or the expires parameter within the Contact header, set to the value of 600 000 seconds as the 
value desired for the duration of the registration; 

NOTE 3: The registrar (S-CCF) might decrease the duration of the registration in accordance with network policy. 

Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 

g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) the Security-Client header field set to specify the security mechanism the UE supports, the IPsec layer 
algorithms the UE supports and the parameters needed for the security association setup. The UE shall support 
the setup of two pairs of security associations as defined in 3GPP TS 33.203 [19]. The syntax of the parameters 
needed for the security association setup is specified in annex H of 3GPP TS 33.203 [19]. The UE shall support 
the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The UE shall support the IPsec layer 
algorithms for integrity and confidentiality protection as defined in 3GPP TS 33.203 [19] and shall announce 
support for them according to the procedures defined in RFC 3329 [48]; 

i) the Supported header containing the option tag "path", and if GRUU is supported, the option tag "gruu"; and 

j) if a security association exists, and if available to the UE (as defined in the access technology specific annexes 
for each access technology), a P-Access-Network-Info header set as specified for the access network technology 
(see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall: 

a) store the expiration time of the registration for the public user identities found in the To header value; 

b) store as the default public user identity the first URI on the list of URIs present in the P-Associated-URI header; 

NOTE 4: The UE can utilize additional URIs contained in the P-Associated-URI header, e.g. for application 

purposes. 

c) treat the identity under registration as a barred pubUc user identity, if it is not included in the 
P-Associated-URI header; 

d) store the list of Service-Route headers contained in the Service-Route header, in order to build a proper 
preloaded Route header value for new dialogs and standalone transactions; 

e) set the security association lifetime to the longest of either the previously existing security association lifetime (if 
available), or the lifetime of the just completed registration plus 30 seconds; and 

NOTE 5: If the UE receives Authentication-Info, it will proceed as described in RFC 3310 [49]. 

f) find the Contact header within the response that matches the one included in the REGISTER request. If this 
contains a "pub-gruu" parameter or a "temp-gruu" parameter or both, and the UE supports GRUU (see table A.4, 
item A.4/53), then store the value of those parameters as the GRUUs for the UE in association with the public 
user identity that was registered. 

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in 
subclause 5.1.1.5.1. 
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On receiving a 305 (Use Proxy) response to the initial REGISTER request, the UE shall: 

a) release all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2; 

b) initiate a new P-CSCF discovery procedure as described in subclause 9.2.1; 

c) select a P-CSCF address, which is different from the previously used address, from the address Ust; and 

d) perform the procedures for initial registration as described in subclause 5 . 1 . 1 .2. 

On receiving the 420 (Bad Extension) response with the Unsupported header containing the option tag 'sec-agree' to the 
REGISTER request, the UE may send another REGISTER request without a security association based on the 
procedures described in 5.1.1.2A. The decision mav depend on the UE's capability. 

On receiving a 423 (Interval Too Brief) too brief response to the REGISTER request, the UE shall: 

send another REGISTER request populating the Expires header or the expires parameter with an expiration timer 
of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response. 

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) or 
600 (Busy Everywhere) response for an initial registration, the UE may attempt to perform initial registration again. 

When the timer F expires at the UE, the UE may: 

a) select a different P-CSCF address from the Ust of P-CSCF addresses discovered during the procedures described 

in subclause 9.2.1; 

b) if no response has been received when attempting to contact all P-CSCFs known by the UE, the UE may get a 
new set of P-CSCF-addresses as described in subclause 9.2.1; and 

c) perform the procedures for initial registration as described in subclause 5 . 1 . 1 .2. 

NOTE 6: It is an implementation option whether these actions are also triggered by other means than expiration of 
timer F, e.g. based on ICMP messages. 

After a maximum of 5 consecutive unsuccessful initial registration attempts, the UE shall not automatically attempt any 
further initial registration via the same network and the same P-CSCF, for an implementation dependant time of at least: 

a) the amount of time indicated in the Retry-After header of the 4xx, 5xx, or 6xx response received in response to 
the most recent registration request, if that header was present; or 

b) 30 minutes, if the header was not present and the initial registration was automatically performed as a 

consequence of a failed reregistration; or 

c) 5 minutes, if the header was not present and the initial registration was not performed as a consequence of a 
failed reregistration. 

These limits do not apply if the UE is power cycled. 

5.1.1.2A Initial registration without security association setup 

The UE can register a public user identity with its contact address at any time after it has acquired an IP address, 
discovered a P-CSCF, and established an IP-CAN bearer that can be used for SIP signalling. However, the UE shall 
only initiate a new registration procedure when it has received a final response from the registrar for the ongoing 
registration, or the previous REGISTER request has timed out. 

The UE shall send the initial REGISTER requests to the port advertised to the UE during the P-CSCF discovery 
procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, the UE 
shall send the initial REGISTER request to the SIP default port values as specified in RFC 3261 |26|. 

The UE shall extract or derive a public user identity, and the domain name to be used in the Request-URl in the 
registration, according to the procedures described in subclause 5. 1.1. IB. A public user identity may be input by the end 
user. The UE may also extract or derive the private user identity according to the procedures described in 
subclause 5. 1.1. IB. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 
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a) optionally, an Authorization header, with the usemame field, set to the value of the private user identity; 

NOTE 1 : In case the Authorization header is absent, the mechanism only supports that one public user identity is 

associated with only one private user identity. 

b) a From header set to the SIP URI that contains the public user identity to be registered; 

c) a To header set to the SIP URI that contains the public user identity to be registered; 

d) a Contact header set to include SIP URI(s) containing the IP address of the UE in the hostport parameter or 
FQDN. If the UE supports GRUU (see table A. 4, item A.4/53), it shall include a +sip. instance parameter 
containing the instance ID. The UE shall include all supported ICSI values (coded as specified in 
subclause 7.2A.8.2). and lARI values (coded as specified in subclause 7.2A.9.2). for the IMS communication 
services and IMS applications it intends to use in a sip .app- subtype feature tag according to draft-rosenberg-sip- 
app-media-tag [1201 and RFC 3840 [621; and 

e) a Via header set to include the IP address or FQDN of the UE in the sent-by field; 

f) an Expires header, or the expires parameter within the Contact header, set to the value of 600 000 seconds as the 
value desired for the duration of the registration; 

NOTE 2: The registrar (S-CCF) might decrease the duration of the registration in accordance with network policy. 

Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 

g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) the Supported header containing the option tag "path", and if GRUU is supported, the option tag "gruu"; and 

i) if available to the UE (as defined in the access technology specific annexes for each access technology), the 
P-Access-Network-Info header set as specified for the access network technology (see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall: 

a) store the expiration time of the registration for the pubhc user identities found in the To header value; 

b) store the list of URIs contained in the P-Associated-URI header value. This list contains the URIs that are 
associated to the registered pubhc user identity; 

c) store as the default public user identity the first URI on the list of URIs present in the P-Associated-URI header; 

d) treat the identity under registration as a barred pubhc user identity, if it is not included in the 
P-Associated-URI header; 

e) store the hst of Service-Route headers contained in the Service-Route header, in order to build a proper 
preloaded Route header value for new dialogs and standalone transactions; and 

NOTE 3: If the UE receives Authentication-Info, it will proceed as described in RFC 3310 [49]. 

f) find the Contact header within the response that matches the one included in the REGISTER request. If this 
contains a "pub-gruu" parameter or a "temp-gruu" parameter or both, and the UE supports GRUU (see table A.4. 
item A.4/53). then store the value of those parameters as the GRUUs for the UE in association with the public 
user identity that was registered. 

On receiving a 305 (Use Proxy) response to the initial REGISTER request, the UE shall: 

a) release all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2; 

b) initiate a new P-CSCF discovery procedure as described in subclause 9.2.1; 

c) select a P-CSCF address, which is different from the previously used address, from the address hst; and 

d) perform the procedures for initial registration as described in subclause 5 . 1 . 1 .2. 

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) or 
600 (Busy Everywhere) response for an initial registration, the UE may attempt to perform initial registration again. 
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When the timer F expires at the UE, the UE may: 

a) select a different P-CSCF address from the hst of P-CSCF addresses discovered during the procedures described 
in subclause 9.2.1; 

b) if no response has been received when attempting to contact all P-CSCFs known by the UE, the UE may get a 
new set of P-CSCF-addresses as described in subclause 9.2.1; and 

c) perform the procedures for initial registration as described in subclause 5.1.1 .2A. 

NOTE 4: It is an implementation option whether these actions are also triggered by other means than expiration of 
timer F, e.g. based on ICMP messages. 

After a maximum of 5 consecutive unsuccessful initial registration attempts, the UE shall not automatically attempt any 
further initial registration via the same network and the same P-CSCF, for an implementation dependant time of at least: 

a) the amount of time indicated in the Retry- After header of the 4xx, 5xx. or 6xx response received in response to 
the most recent registration request, if that header was present; or 

b) 30 minutes, if the header was not present and the initial registration was automatically performed as a 
consequence of a failed reregistration; or 

c) 5 minutes, if the header was not present and the initial registration was not performed as a consequence of a 

failed reregistration. 

These limits do not apply if the UE is power cycled. 

On receiving a 423 (Interval Too Brief) too brief response to the REGISTER request, the UE shall: 

send another REGISTER request populating the Expires header or the expires parameter with an expiration timer 
of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response. 

5.1 .1 .3 Subscription to the registration-state event package 

Upon receipt of a 2xx response to the initial registration, the UE shall subscribe to the reg event package for the public 
user identity registered at the user's registrar (S-CCF) as described in RFC 3680 [43]. 

The UE shall use the default public user identity for subscription to the registration-state event package, if the public 
user identity that was used for initial registration is a barred public user identity. The UE may use either the default 
pubUc user identity or the public user identity used for initial registration for the subscription to the registration-state 
event package, if the initial pubhc user identity that was used for initial registration is not barred. 

On sending a SUBSCRIBE request, the UE shall populate the header fields as follows: 

a) a Request URI set to the resource to which the UE wants to be subscribed to, i.e. to a SIP URI that contains the 
public user identity used for subscription; 

b) a From header set to a SIP URI that contains the pubhc user identity used for subscription; 

c) a To header set to a SIP URI that contains the pubhc user identity used for subscription; 

d) an Event header set to the "reg" event package; 

e) an Expires header set to 600 000 seconds as the value desired for the duration of the subscription 

f) if available to the UE (as defined in the access technology specific annexes for each access technology), a 
P-Access-Network-Info header set as specified for the access network technology (see subclause 7.2A.4); and 

g) a Contact header set to contain the same IP address or FQDN, and when a security association exists with the 
protected server port value as in the initial registration. 

Upon receipt of a 2xx response to the SUBSCRIBE request, the UE shall store the information for the established 
dialog and the expiration time as indicated in the Expires header of the received response. 

If continued subscription is required, the UE shall automatically refresh the subscription by the reg event package, for a 
previously registered public user identity, either 600 seconds before the expiration time if the initial subscription was 
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for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 1200 seconds or 
less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the UE shall still consider the 
original subscription valid for the duration of the most recently known "Expires" value according to RFC 3265 [28]. 
Otherwise, the UE shall consider the subscription invalid and start a new initial subscription according to 
RFC 3265 [28]. 

5.1 .1 .4 User-initiated re-registration and registration of an additional public user identity (with 

security association) 

The UE can perform the reregistration of a previously registered public user identity with its contact address at any time 
after the initial registration has been completed. The UE shall perform the reregistration over the existing set of security 
associations that is associated with the related contact address. 

The UE can perform registration of additional public user identities at any time after the initial registration has been 
completed. The UE shall perform the registration of additional public user identities over the existing set of security 
associations that is associated with the related contact address. 

Unless either the user or the application within the UE has determined that a continued registration is not required the 
UE shall reregister an already registered public user identity either 600 seconds before the expiration time if the 
previous registration was for greater than 1200 seconds, or when half of the time has expired if the initial registration 
was for 1200 seconds or less, or when the UE intends to update its capabiUties according to RFC 3840 [62] or when the 
UE needs to modify the ICSl values that the UE intends to use in a g.3gpp.icsi-ref feature tag or lARI values that the 
UE intends to use in the g.3gpp.iari-re f sip.app subtype feature tag. 

The UE shall protect the REGISTER request using a security association, see 3GPP TS 33.203 [19], established as a 

result of an earlier registration, if one is available. 

The UE shall extract or derive a pubUc user identity, the private user identity, and the domain name to be used in the 
Request-URI in the registration, according to the procedures described in subclause 5. 1.1.1 A. 

On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as 
follows: 

a) an Authorization header, with: 

the usemame directive set to the value of the private user identity; 

the realm directive, set to the value as received in the realm directive in the WWW Authenticate header; 
the uri directive, set to the SIP URI of the domain name of the home network; 

- the nonce directive, set to last received nonce value; and 

- the response directive, set to the last calculated response value; 

b) a From header set to the SIP URI that contains the public user identity to be registered; 

c) a To header set to the SIP URI that contains the public user identity to be registered; 

d) a Contact header set to include SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or 
FQDN and protected server port value bound to the security association, and containing the instance ID of the 
UE in the H-sip.instance parameter, if the UE supports GRUU (see table A.4, item A.4/53). The UE shall include 
all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref feature tag as defined in 
subclause 7.9.2 and RFC 3840 [62] for the IMS communication it intends to use , and lARI values (coded as 
specified in subclause 7.2A.9.2), for the IMS communication services and IMS applications it intends to use in a 
g.3gpp.iari-ref sip.app subtype feature tag according to draft rosenberg sip app media tag [120] as defined in 
subclause 7.9.3 and RFC 3840 [62]; 

e) a Via header set to include the IP address or FQDN of the UE in the sent-by field and for the UDP the protected 
server port value bound to the security association, while for the TCP, the response is received on the TCP 
connection on which the request was sent; 

NOTE 1: If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 

Via header, then it has to ensure that the given FQDN wiU resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 
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NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security 
associations. For details on the selection of the protected port value see 3GPP TS 33.203 1 19|. 

f) an Expires header, or an expires parameter within the Contact header, set to 600 000 seconds as the value desired 
for the duration of the registration; 

NOTE 3: The registrar (S-CCF) might decrease the duration of the registration in accordance with network policy. 

Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 

g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) a Security-Client header field, set to specify the security mechanism it supports, the IPsec layer algorithms for 
security and confidentiality protection it supports and the new parameter values needed for the setup of two new 
pairs of security associations. For further details see 3GPP TS 33.203 [19] and RFC 3329 [48]; 

i) a Security- Verify header that contains the content of the Security-Server header received in the 401 
(Unauthorized) response of the last successful authentication; 

j) the Supported header containing the option tag "path", and if GRUU is supported, the option tag "gruu"; and 

k) if available to the UE (as defined in the access technology specific annexes for each access technology), a 
P-Access-Network-Info header set as specified for the access network technology (see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall: 

a) store the new expiration time of the registration for this public user identity found in the To header value; 

b) store the list of Service-Route headers contained in the Service-Route header, in order to build a proper 
preloaded Route header value for new dialogs and standalone transactions; 

NOTE 4: The UE can utilize additional URIs contained in the P-Associated-URI header, e.g. for application 
purposes. 

c) set the security association lifetime to the longest of either the previously existing security association lifetime, 
or the lifetime of the just completed registration plus 30 seconds; and 

NOTE 5: If the UE receives Authentication-Info, it will proceed as described in RFC 3310 [49]. 

d) find the Contact header within the response that matches the one included in the REGISTER request. If this 
contains a "pub-gruu" parameter or a "temp-gruu" parameter or both, and the UE supports GRUU (see table A.4, 
item A.4/53), then store the value of those parameters as the GRUUs for the UE in association with the public 
user identity that was registered. 

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in 
subclause 5.1.1.5.1. 

On receiving the 420 (Bad Extension) response with the Unsupported header containing the option tag 'sec-agree' to the 
REGISTER request, the UE may send another REGISTER request without a security association based on the 
procedures described in 5.1.1.2A. The decision may depend on the UE's capability. 

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall: 

- send another REGISTER request populating the Expires header or the expires parameter with an expiration timer 
of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response. 

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) 
response for a reregistration, the UE shall perform the procedures for initial registration as described in 
subclause 5.1.1.2. 

On receiving a 305 (Use Proxy) response to the REGISTER request, the UE shall: 

a) release all IP -CAN bearers used for the transport of media according to the procedures in subclause 9.2.2; 

b) initiate a new P-CSCF discovery procedure as described in subclause 9.2.1; 

c) select a P-CSCF address, which is different from the previously used address, from the address list; and 
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d) perform the procedures for initial registi^ation as described in subclause 5 . 1 . 1 .2. 
When the timer F expires at the UE, the UE shall: 

1) stop processing of all ongoing dialogs and transactions and silently discard them locally; and 

2) after releasing all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2, 
the UE may: 

a) select a different P-CSCF address from the hst of P-CSCF addresses discovered during the procedures 
described in subclause 9.2.1; 

b) if no response has been received when attempting to contact all P-CSCFs known by the UE, the UE may get 
a new set of P-CSCF-addresses as described in subclause 9.2.1; and 

c) perform the procedures for initial registration as described in subclause 5.1.1.2. 

NOTE 6: It is an implementation option whether these actions are also triggered by other means than expiration of 
timer F, e.g. based on ICMP messages. 

5.1.1.4A User-initiated re-registration and registration of an additional public user identity 

witliout security association 

The UE can perform the reregistration of a previouslv registered public user identity with its contact address at any time 
after the initial registration has been completed. 

The UE can perform registration of additional pubhc user identities at any time after the initial registration has been 
completed. 

Unless either the user or the application within the UE has determined that a continued registration is not required the 

UE shall reregister an already registered public user identity either 600 seconds before the expiration time if the 
previous registration was for greater than 1200 seconds, or when half of the time has expired if the initial registration 
was for 1200 seconds or less, or when the UE intends to update its capabilities according to RFC 3840 [621 or when the 
UE needs to modify the ICSI values or lARI values that the UE intends to use in the sip.app-subtype feature tag. 

The UE shall extract or derive a public user identity, and the domain name to be used in the Request-URl in the 
registration, according to the procedures described in subclause 5. 1.1. IB. The UE may also extract or derive the private 
user identity according to the procedures described in subclause 5. 1.1. IB. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 

a) optionally, an Authorization header, with the username field, set to the value of the private user identity; 

NOTE 1 : In case the Authorization header is absent, the mechanism only supports that one public user identity is 
associated with only one private user identity. 

b) a From header set to the SIP URI that contains the public user identity to be registered; 

c) a To header set to the SIP URl that contains the public user identity to be registered; 

d) a Contact header set to include SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or 
FODN, and containing the instance ID of the UE in the H-sip.instance parameter, if the UE supports GRUU (see 
table A.4, item A.4/53). The UE shall include all supported ICSl values (coded as specified in 

subclause 7.2A.8.2), and lARl values (coded as specified in subclause 7.2A.9.2), for the IMS communication 
services and IMS applications it intends to use in a sip.app-subtype feature tag according to 
draft-rosenberg-sip-app-media-tag [1201 and RFC 3840 [621; 

e) a Via header set to include the IP address or FODN of the UE in the sent-by field; 

f) an Expires header, or an expires parameter within the Contact header, set to 600 000 seconds as the value desired 
for the duration of the registration; 

NOTE 2: The registrar (S-CCF) might decrease the duration of the registration in accordance with network policy. 
Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 
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g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) the Supported header containing the option tag "path", and if GRUU is supported, the option tag "gruu"; and 

i) if available to the UE (as defined in the access technology specific annexes for each access technology), a 
P-Access-Network-Info header set as specified for the access network technology (see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall: 

a) store the new expiration time of the registration for this public user identity found in the To header value; 

NOTE 3: The UE can utiUze additional URIs contained in the P-Associated-URI header, e.g. for application 
purposes. 

b) store the list of Service-Route headers contained in the Service-Route header, in order to build a proper 
preloaded Route header value for new dialogs and standalone transactions; and 

NOTE 4: If the UE receives Authentication-Info, it will proceed as described in RFC 33 10 [491. 

c) find the Contact header within the response that matches the one included in the REGISTER request. If this 
contains a "pub-gruu" parameter or a "temp-gruu" parameter or both, and the UE supports GRUU (see table A.4. 
item A.4/53). then store the value of those parameters as the GRUUs for the UE in association with the public 
user identity that was registered. 

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall: 

send another REGISTER request populating the Expires header or the expires parameter with an expiration timer 
of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response. 

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) 
response for a reregistration. the UE shall perform the procedures for initial registration as described in 
subclause 5.1.1 ■2A. 

On receiving a 305 (Use Proxy) response to the REGISTER request, the UE shall: 

a) release all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2; 

b) initiate a new P-CSCF discovery procedure as described in subclause 9.2.1; 

c) select a P-CSCF address, which is different from the previously used address, from the address hst; and 

d) perform the procedures for initial registration as described in subclause 5 . 1 . 1 ■2A. 
When the timer F expires at the UE. the UE shall: 

1) stop processing of all ongoing dialogs and transactions and silently discard them locally; and 

2) after releasing all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2. 
the UE may: 

a) select a different P-CSCF address from the hst of P-CSCF addresses discovered during the procedures 
described in subclause 9.2.1; 

b) if no response has been received when attempting to contact all P-CSCFs known by the UE. the UE may get 
a new set of P-CSCF-addresses as described in subclause 9.2.1; and 

c) perform the procedures for initial registration as described in subclause 5.1.1 .2 A. 

NOTE 5: It is an implementation option whether these actions are also triggered by other means than expiration of 
timer F. e.g. based on ICMP messages. 

After a maximum of 5 consecutive initial registration attempts, the UE shall not automatically attempt any further initial 
registration for an implementation dependant time of at least 30 minutes. 
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5.1.1.5.1 General 

Authentication is performed during initial registration as defined in subclause 5.1.1.2 . A UE can be re-authenticated 
during subsequent re-registration s, deregistrations or registrations of additional public user identities as defined in 
subclause 5. 1.1 .4 . When the network requires authentication or re-authentication of the UE, the UE will receive a 401 
(Unauthorized) response to the REGISTER request. 

On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall: 

1) extract the RAND and AUTN parameters; 

2) check the vaUdity of a received authentication challenge, as described in 3GPP TS 33.203 [19] i.e. the locally 
calculated XMAC must match the MAC parameter derived from the AUTN part of the challenge; and the SQN 
parameter derived from the AUTN part of the challenge must be within the correct range; and 

3) check the existence of the Security-Server header as described in RFC 3329 [48]. If the header is not present or it 
does not contain the parameters required for the setup of the set of security associations (see annex H of 

3GPP TS 33.203 [19]), the UE shall abandon the authentication procedure and send a new REGISTER request 
with a new CaU-ID. 

In the case that the 401 (Unauthorized) response to the REGISTER request is deemed to be vaUd the UE shall: 

1) calculate the RES parameter and derive the keys CK and IK from RAND as described in 3GPP TS 33.203 [19]; 

2) set up a temporary set of security associations based on the static list and parameters it received in the 401 
(Unauthorized) response and its capabilities sent in the Security-Chent header in the REGISTER request. The 
UE sets up the temporary set of security associations using the most preferred mechanism and algorithm returned 
by the P-CSCF and supported by the UE and using IK and CK (only if encryption enabled) as the shared key. 
The UE shall use the parameters received in the Security-Server header to setup the temporary set of security 
associations. The UE shall set a temporary SIP level lifetime for the temporary set of security associations to the 
value of reg-await-auth timer; and 

3) send another REGISTER request using the temporary set of security associations to protect the message. The 
header fields are populated as defined for the initial request, with the addition that the UE shall include an 
Authorization header containing: 

the realm directive set to the value as received in the realm directive in the WWW Authenticate header; 

- the username directive, set to the value of , the private user identity;-aBd- 

- the response directive that contains the authentication challenge response calculated by the UE using RES 
and other parameters, as described in RFC 3310 |49]; 

the uri directive, set to the SIP URl of the domain name of the home network; 

- the algorithm directive, set to the value received in the 401 (Unauthorized) response; and 

- the nonce directive, set to the value received in the 401 (Unauthorized) response . 
The UE shall also insert the 

Security-Client header that is identical to the Security-CUent header that was included in the previous 
REGISTER request (i.e. the REGISTER request that was challenged with the received 401 (Unauthorized) 
response). The UE shall also insert the Security-Verify header into the request, by mirroring in it the content of 
the Security-Server header received in the 401 (Unauthorized) response. The UE shall set the Call-ID of the 
security association protected REGISTER request which carries the authentication challenge response to the 
same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge. 

On receiving the 200 (OK) response for the security association protected REGISTER request, the UE shall: 

change the temporary set of security associations to a newly established set of security associations, i.e. set its 
SIP level lifetime to the longest of either the previously existing set of security associations SIP level Ufetime, or 
the lifetime of the just completed registration plus 30 seconds; and 

- use the newly established set of security associations for further messages sent towards the P-CSCF as 
appropriate. 
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NOTE 1: In this case, the UE will send requests towards the P-CSCF over the newly established set of security 
associations. Responses towards the P-CSCF that are sent via UDP will be sent over the newly 
established set of security associations. Responses towards the P-CSCF that are sent via TCP will be sent 
over the same set of security associations that the related request was received on. 

When the first request or response protected with the newly established set of security associations is received from the 
P-CSCF, the UE shall delete the old set of security associations and related keys it may have with the P-CSCF after all 
SIP transactions that use the old set of security associations are completed. 

Whenever the 200 (OK) response is not received before the temporary SIP level lifetime of the temporary set of security 
associations expires or a 403 (Forbidden) response is received, the UE shall consider the registration to have failed. The 
UE shall delete the temporary set of security associations it was trying to estabUsh, and use the old set of security 
associations. The UE should send an unprotected REGISTER message according to the procedure specified in 
subclause 5.1.1.2 if the UE considers the old set of security associations to be no longer active at the P-CSCF. 

In the case that the 401 (Unauthorized) response is deemed to be invalid then the UE shall behave as defined in 
subclause 5.1.1.5.3. 

5.1.1.5.1A NASS-bundled authentication 

NASS-bundled authentication is only applicable to UEs that contain neither USIM nor ISIM. Authentication is achieved 
via the registration and re -registration procedures as defined in subclause 5.1.1.2A and subclause 5.1.1.4A. 
NASS-bundled authentication is granted by the network upon receipt by the UE of a 200 (OK) response to the initial 
REGISTER request. 

5.1 .1 .5.2 Network-initiated re-authentication 

At any time, the UE can receive a NOTIFY request carrying information related to the reg event package (as described 
in subclause 5.1.1.3). If: 

the state attribute in any of the <registration> elements is set to "active"; 

- the value of the <uri> sub-element inside the <contact> sub-element is set to the Contact address that the UE 
registered; and 

- the event attribute of that <contact> sub-element(s) is set to "shortened"; 
the UE shall: 

1) use the expiry attribute within the <contact> sub-element that the UE registered to adjust the expiration time for 
that public user identity; and 

2) start the re-authentication procedures at the appropriate time (as a result of the S-CCF procedure described in 
subclause 5.4.1.6) by initiating a reregistration as described in subclause 5.1.1.4, or subclause 5.1.1.4A if those 
procedures were performed for the initial authentication, i f required. 

NOTE: When authenticating a given private user identity, the S-CCF will only shorten the expiry time within the 
<contact> sub-element that the UE registered using its private user identity. The <contact> elements for 
the same public user identity, if registered by another UE using different private user identities remain 
unchanged. The UE will not initiate a reregistration procedure, if none of its <contact> sub-elements was 
modified. 

5.1 .1 .5A Change of Ipv6 address due to privacy 

Stateless address autoconfiguration as described in RFC 2462 [20E] defines how an IPv6 prefix and an interface 
identifier is used by the UE to construct a complete IPv6 address. 

If the UE receives an IPv6 prefix, the UE may change the interface identity of the IPv6 address as described in 
RFC 3041 [25A] due to privacy but this will result in service discontinuity for IMS services. 

NOTE: The procedure described below will terminate all estabUshed dialogs and transactions and temporarily 

disconnect the UE from the IM CN subsystem until the new registration is performed. Due to this, the UE 
is recommended to provide a limited use of the procedure to ensure a maximum degree of continuous 
service to the end user. 
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In order to change the IPv6 address due to privacy, the UE shall: 

1) terminate all ongoing dialogs (e.g., sessions) and transactions (e.g., subscription to the reg event); 

2) deregister all registered public user identities as described in subclause 5.1.1.6 or subclause 5. 1.1. 6 A as 
appropriate to the authentication mechanism in use ; 

3) construct a new IPv6 address according to the procedures specified in RFC 3041 [25A]; 

4) register the public user identities that were deregistered in step 2 above, as follows: 

a) by performing an initial registration as described in subclause 5.1.1.2 or subclause 5.1.1.2A as appropriate to 
the authentication mechanism in use ; and 

b) by performing a subscription to the reg event package as described in subclause 5.1.1.3; and 

5) subscribe to other event packages it was subscribed to before the change of IPv6 address procedure started. 

5.1 .1 .6 User-initiated deregistration (with security association) 

The UE can deregister a public user identity that it has previously registered with its contact address at any time. 

The UE shall protect the REGISTER request using a security association, see 3GPP TS 33.203 [19], estabhshed as a 
result of an earlier registration, if one is available. 

The UE shall extract or derive a pubhc user identity, the private user identity, and the domain name to be used in the 
Request-URI in the registration, according to the procedures described in subclause 5. 1.1.1 A. 

Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs related to the public user 
identity that is going to be deregistered or to one of the implicitly registered pubhc user identities However: 

- if the dialog that was estabhshed by the UE subscribing to the reg event package used the public user identity 
that is going to be deregistered; and 

- this dialog is the only remaining dialog used for subscription to reg event package; 
then the UE shall not release this dialog. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 

a) an Authorization header, with: 

the username directive, set to the value of the private user identity; 

- the realm directive, set to the value as received in the realm directive in the WWW-Authenticate header; 

- the uri directive, set to the SIP URI of the domain name of the home network; 

- the nonce directive, set to last received nonce value; and 

- the response directive, set to the last calculated response value; 

b) a From header set to the SIP URI that contains the public user identity to be deregistered; 

c) a To header set to the SIP URI that contains the public user identity to be deregistered; 

d) a Contact header set to either the value of "*" or SIP URl(s) that contain(s) in the hostport parameter the IP 
address of the UE or FQDN and the protected server port value bound to the security association, and containing 
the Instance ID of the UE in the +sip.instance parameter, if the UE supports GRUU (see table A.4, item A.4/53); 

e) a Via header set to include the IP address or FQDN of the UE in the sent-by field and the protected server port 
value bound to the security association; 

NOTE 1 : If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 

Via header, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 
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f) an Expires header, or the expires parameter of the Contact header, set to the value of zero, appropriate to the 

deregistration requirements of the user; 

g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) a Security-CUent header field, set to specify the security mechanism it supports, the IPsec layer algorithms for 
integrity and confidentiality protection it supports and the new parameter values needed for the setup of two new 
pairs of security associations. For further details see 3GPP TS 33.203 [19] and RFC 3329 [48]; 

i) a Security- Verify header that contains the content of the Security-Server header received in the 401 
(Unauthorized) response of the last successful authentication; and 

j) if available to the UE (as defined in the access technology specific annexes for each access technology), a 
P-Access-Network-lnfo header set as specified for the access network technology (see subclause 7.2A.4). 

When a 401 (Unauthorized) response to a REGISTER request is received the UE shall behave as described in 
subclause 5.1.1.5.1. 

On receiving the 200 (OK) response to the REGISTER request, the UE shall remove all registration details relating to 
this public user identity. 

If there are no more public user identities registered, the UE shall delete the security associations and related keys it 
may have towards the IM CN subsystem. 

If all public user identities are deregistered and the security association is removed, then the UE shall consider 
subscription to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires 
header containing a value of zero). 

NOTE 2: When the UE has received the 200 (OK) response for the REGISTER request of the only public user 
identity currently registered with its associated set of implicitly registered public user identities (i.e. no 
other is registered), the UE removes the security association estabUshed between the P-CSCF and the UE. 
Therefore further SIP signalling (e.g. the NOTIFY request containing the deregistration event) will not 
reach the UE. 

5.1 .1 .6A User-initiated deregistration without security association 

The UE can deregister a public user identitv that it has previouslv registered with its contact address at anv time. 

The UE shall extract or derive a public user identitv and the domain name to be used in the Request-URI in the 
registration, according to the procedures described in subclause 5. 1.1. IB. The UE mav also extract or derive the private 
user identitv according to the procedures described in subclause 5. 1.1. IB. 

Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs related to the public user 
identitv that is going to be deregistered or to one of the implicitly registered public user identities. However: 

if the dialog that was established bv the UE subscribing to the reg event package used the public user identitv 
that is going to be deregistered; and 

- this dialog is the onlv remaining dialog used for subscription to reg event package; 

then the UE shall not release this dialog. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 

a) optionally, an Authorization header, with the usemame directive, set to the value of the private user identitv; 

NOTE: In case the Aulhori/alion header is absent, the mechanism only supports that one public user idenlily is 
associated with only one private user identitv. 

b) a From header set to the SIP URI that contains the public user identitv to be deregistered; 

c) a To header set to the SIP URI that contains the public user identitv to be deregistered; 

d) a Contact header set to either the value of "*" or SIP URI(s) that contain(s) in the hostport parameter the IP 
address of the UE or FQDN, and containing the Instance ID of the UE in the -Hsip.instance parameter, if the UE 
supports GRUU (see table A.4, item A.4/53); 
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e) a Via header set to include the IP address or FQDN of the UE in the sent-by field; 

f) an Expires header, or the expires parameter of the Contact header, set to the value of zero, appropriate to the 
deregistration requirements of the user; 

g) a Request-URI set to the SIP URI of the domain name of the home network; and 

h) if available to the UE (as defined in the access technology specific annexes for each access technology), a 
P-Access-Network-lnfo header set as specified for the access network technology (see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall remove all registration details relating to 

this public user identity. 

If all public user identities are deregistered, then the UE shall consider subscription to the reg event package cancelled 
(i.e. as if the UE had sent a SUBSCRIBE request with an Expires header containing a value of zero). 

5.1 .1 .7 Network-initiated deregistration 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package as 
described in subclause 5.1.1.3, including one or more <registration> element(s) which were registered by this UE with: 

- the state attribute set to "terminated" and the event attribute within the <contact> element belonging to this UE 
set to "rejected" or "deactivated"; or 

- the state attribute set to "active" and within the <contact> element belonging to this UE, the state attribute set to 
"terminated" and the associated event attribute set to "rejected" or "deactivated"; 

the UE shall remove all registration details relating to these public user identities. In case of a "deactivated" event 
attribute, the UE shall start the initial registration procedure as described in subclause 5.1.1.2. or subclause 5.1.1 .2A . In 
case of a "rejected" event attribute, the UE shall release all dialogs related to those public user identities. 

Upon receipt of a NOTIFY request, the UE shall delete the security associations (if present) towards the P-CSCF either: 

- if all <registration> element(s) have their state attribute set to "terminated" (i.e. all pubhc user identities are 
deregistered) and the Subscription-State header contains the value of "terminated"; or 

- if each <registration> element that was registered by this UE has either the state attribute set to "terminated", or 
the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to 
"terminated". 

The UE shall delete these security associations (if present) towards the P-CSCF after the server transaction (as defined 
in RFC 3261 [26]) pertaining to the received NOTIFY request terminates. 

NOTE 1 : Deleting a security association is an internal procedure of the UE and does not involve any SIP 
procedures. 

NOTE 2: If all the public user identities or contact addresses registered by this UE are deregistered and the security 
association is removed, the UE considers the subscription to the reg event package terminated since the 
NOTIFY request was received with Subscription-State header containing the value of "terminated". 

5.1 .2.1 Notification about multiple registered public user identities 

Upon receipt of a 2xx response to the SUBSCRIBE request the UE shall maintain the generated dialog (identified by 
the values of the CaU-ID header , and the values of tags in T o and From headers). 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package the 
UE shall perform the following actions: 

if a state attribute "active", i.e. registered is received for one or more public user identities, the UE shall store the 
indicated public user identities as registered; 

- if a state attribute "active" is received, and the UE supports GRUU (see table A.4, item A.4/53), then for each 
public user identity indicated in the notification that contains a <pub-gruu> element or a <temp-gruu> element or 
both (as defined in draft-ietf-sipping-gruu-reg-event [94]) then the UE shall store the value of those elements in 
association with the public user identity; 
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if a state attribute "terminated", i.e. deregistered is received for one or more public user identities, the UE shall 
store the indicated public user identities as deregistered and shall remove any associated GRUUs. 

NOTE_l_: There may be public user identities which are automatically registered within the registrar (S-CSCF) of 
the user upon registration of one public user identity or when S-CSCF receives a Push-Profile-Request 
(PPR) from the HSS (as described in 3GPP TS 29.228 [14]) changing the status of a public user identity 
associated with a registered implicit set from barred to non-barred. Usually these automatically or 
implicitly registered public user identities belong to the same service profile of the user and they might 
not be available within the UE. The implicitly registered public user identities may also belong to 
different service profiles. The here-described procedures provide a different mechanism (to the 200 (OK) 
response to the REGISTER request) to inform the UE about these automatically registered pubUc user 
identities. 

NOTE 2: draft-ietf-sipping-gruu-reg-event [941 provides guidance on the management of temporary GRUUs. 
utilizing information provided in the reg event notification. 

5.1.2A.1 UE-originating case 

The procedures of this subclause are general to all requests and responses, except those for the REGISTER method. 

If a security association exists , when the UE sends any request, the UE shall send the request to the protected port 
received during registration as described in subclause 5.1.1.5.1 with : 

- include i ncluding the protected server port in the Via header entry relating to the UE. 

Otherwise if no security association exists, i.e. no port is provided for subsequent SIP messages by P-CSCF during 
registration, the UE shall send any request to the same port used for the initial registration as described in 
subclause 5.1.1.2A. 

If a security association exists , the UE shall discard any SIP response that is not protected by the security association 
and is received from the P-CSCF outside of the registration and authentication procedures. The requirements on the UE 
within the registration and authentication procedures are defined in subclause 5.1.1. 

In accordance with RFC 3325 [34] the UE may insert a P-Preferred-Identity header in any initial request for a dialog or 
request for a standalone transaction as a hint for creation of an asserted identity (contained in the P-Asserted-Identity 
header) within the IM CN subsystem. 

NOTE 1: Since the S-CCF uses the P-Asserted-ldentity header when checking whether the UE originating request 
matches the initial filter criteria, the P-Preferred-Identity header inserted by the UE determines which 
services and applications are invoked. 

The UE may include any of the following in the P-Preferred-Identity header: 

- a public user identity which has been registered by the user; 

- a public user identity retumed in a registration-state event package of a NOTIFY request as a result of an implicit 
registration that was not subsequently deregistered or has expired; or 

- any other public user identity which the user has assumed by mechanisms outside the scope of this specification 
to have a current registration. 

NOTE 2: The temporary public user identity specified in subclause 5 . 1 . 1 . 1 is not a pubhc user identity suitable for 
use in the P-Preferred-Identity header. 

NOTE 3: Procedures in the network require international public telecommunication numbers when telephone 
numbers are used in P-Preferred-Identity header. 

NOTE 4: A number of headers can reveal information about the identity of the user. Where privacy is required, 

implementers should also give consideration to other headers that can reveal identity information. 
RFC 3323 [33] subclause 4.1 gives considerations relating to a number of headers. 

Where privacy is required, in any initial request for a dialog or request for a standalone transaction, the UE shall set the 
From header to "Anonymous" as specified in RFC 3261 [26]. 
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NOTE 5: The contents of the From header should not be reHed upon to be modified by the network based on any 
privacy specified by the user either within the UE indication of privacy or by network subscription or 
network policy. Therefore the user should include the value "Anonymous" whenever privacy is expUcitly 
required. As the user may well have privacy requirements, terminal manufacturers should not 
automatically derive and include values in this header from the pubUc user identity or other values stored 
in or derived from the UICC. Where the user has not expressed a preference in the configuration of the 
terminal implementation, the implementation should assume that privacy is required. Users that require to 
identify themselves, and are making calls to SIP destinations beyond the IM CN subsystem, where the 
destination does not implement RFC 3325 [34], will need to include a value in the From header other than 
Anonymous. 

The UE shall determine the pubUc user identity to be used for this request as follows: 

1) if a P-Preferred-Identity was included, then use that as the pubUc user identity for this request; or 

2) if no P-Preferred-ldentity was included, then use the default pubUc user identity for the security association as 
the public user identity for this request; 

If this is a request for a new dialog, and the request includes a Contact header, then the UE should populate the Contact 

header as follows: 

1) if a pubhc GRUU value (pub-gruu) has been saved associated with the pubhc user identity to be used for this 
request, and the UE does not indicate privacy of the P-Asserted-Identity, then insert the public GRUU 
(pub-gruu) value in the Contact header as specified in draft-ietf-sip-gruu [93];-er 

2) if a temporary GRUU value (temp-gruu) has been saved associated with the public user identity to be used for 
this request, and the UE does indicate privacy of the P-Asserted-Identity, then insert the temporary GRUU 
(temp-gruu) value in the Contact header as specified in draft-ietf-sip-gruu [93];-er 

NOTE 5A: The above items 1 and 2 are mutuallv exclusive. 

3) if the request is related to an IMS communication service that requires the use of an ICSI then shall include in a 
g.3gpp.icsi-ref feature tag as defined in subclause 7.9.2 and RFC 3841 [5661 in a sip.app subtype feature tag the 
ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service and may include the 
lARI value (coded as specified in subclause 7.2A.9.2), that is related to the request according to draft rosenberg 
sip app media tag [120] and RFC 3841 [56B] . The UE may also include other ICSI values that the UE is 
prepared to use for the communication and other lARI values for all dialogs with the terminating UE(s) the IMS 
application that is related to the IMS communication service ; er and 

4) if the request is related to an IMS application that is supported by the UE when the use of an ICSI is not needed , 
then may include the lARI value (coded as specified in subclause 7.2A.9.2), that is related to any the to the IMS 
application and that applies for the dialog, in a g.3gpp.iari-ref feature tag as defined in subclause 7.9.3 , according 
to draft rosenberg sip app media tag [120] and RFC 3841 [56B] . 

NOTE 5B: The above items 3 and 4 are mutually exclusive. 

If this is a request within an existing dialog, and the request includes a Contact header, and the Contact address 
previously used in the dialog was a GRUU, then the UE should insert the previously used GRUU value in the Contact 
header as specified in draft-ietf-sip-gruu [93]. 

If the UE did not insert a GRUU in the Contact header, then the UE shall include the protected server port in the address 
in the Contact header. 

If this is a request for a new dialog or standalone transaction and the request is related to an IMS communication service 
that requires the use of an ICSI then the UE: 

1) shall include the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service that 
is related to the request in a P-Preferred-Service header field according to draft-drage-sipping-service- 
identification [121]; 

NOTE 5A: The UE onlv receives those ICSI values correponding to the IMS communication services that the 
network provides to the user. 

2) may include an Accept-Contact header field containing an ICSI value (coded as specified in subclause 7.2A.8.2) 
or an lARI value (coded as specified in subclause 7.2A.9.2) that is related to the request in a g.3gpp.icsi-ref 
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sip.app subtype feature tag as defined in subclause 7.9.2 accorcling to draft rosenberg sip app media tag [1201 
and RFC 381 1 [566] if the ICSI or lARI for the IMS communication service is known. 

Editor's note: It is FFS whether the UE shall always include an ICSI value in an Accept-Contact header field. This 
also may need some clarifications to the stage 2 text to fuUy align. 

Editor's Note: If the UE includes (as mandated) the same ICSI values into the Accept-Contact header and the 

P-Preferred-Service header, there is a possibility that one of the involved S-CCFs or an AS changes the 
ICSI value in the P-Asserted-Service header, which results in the message including two different ICSI 
values (one in the P-Asserted-Service header, changed in the network and one in the Accept-Contact 
header). 

If an IMS application indicates that an lARI is to be included in a request for a new dialog or standalone transaction, the 
UE shall include an Accept-Contact header field containing an lARI value (coded as specified in subclause 7.2A.9.2) 
that is related to the request in a g.3gpp.iari-ref feature tag as defined in subclause 7.9.3 and RFC 3841 [56B|. 

NOTE 6: RFC 3841 [56B] allows multiple Accept-Contact header fields along with multiple Reject-Contact header 
fields in a SIP request, and within those header fields, expressions that include one or more logical 
operations based on combinations of feature tags. Which registered UE will be contacted depends on the 
Accept-Contact header field and Reject-Contact header field combinations included that evaluate to a 
logical expression and the relative qvalues of the registered contacts for the targeted registered public user 
identity. There is therefore no guarantee that when multiple Accept-Contact header fields or additional 
Reject-Contact header field(s) along with the Accept-Contact header field containing the ICSI value or 
lARI value are included in a request that the request will be routed to a contact that registered the same 
ICSI value or lARI value. Charging and accounting is based upon the contents of the P-Asserted-Service 
header field and the actual media related contents of the SIP request and not the Accept-Contact header 
field contents or the contact reached. 

NOTE 7: The UE only includes the parameters require and explicit in the Accept-Contact header field containing 
the ICSI value or lARI value if the IMS communication service absolutely requires that the terminating 
UE understand the IMS communication service in order to be able to accept the session. Including the 
parameters require and explicit in Accept-Contact header fields in requests which do not absolutely 
require that the terminating UE understand the IMS communication service in order to accept the session 
creates an interoperability problem for sessions which otherwise would interoperate and violates the 
interoperability requirements for the ICSI IMS Communication Service Identifier in 3 GPP TS 23.228 [7]. 

After the dialog is established the UE may change the dialog capabilities (e.g. add a media or request a supplementary 
service) if defined for the IMS communication service as identified by the ICSI value using the same dialog. Otherwise, 
the UE shall initiate a new initial request to the other user. 

The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance with 
RFC 3323 [33], and the additional requirements contained within RFC 3325 [34]. 

If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall 
insert a P- Access-Network-Info header into any request for a dialog, any subsequent request (except ACK requests and 
CANCEL requests) or response (except CANCEL responses) within a dialog or any request for a standalone method 
(see subclause 7.2A.4). 

NOTE 8: During the dialog, the points of attachment to the IP-CAN of the UE may change (e.g. UE connects to 
different cells). The UE will populate the P- Access-Network-Info header in any request or response 
within a dialog with the current point of attachment to the IP -CAN (e.g. the current cell information). 

The UE shall build a proper preloaded Route header value for all new dialogs and standalone transactions. The UE shall 
build a list of Route header values made out of, in this order, the P-CSCF URI (containing the IP address or the FQDN 
learnt through the P-CSCF discovery procedures, and the protected server port learnt during the registration procedure), 
and the values received in the Service-Route header saved from the 200 (OK) response to the last registration or 
re-registration. 

The UE may indicate that proxies should not fork the request by including a "no-fork" directive within the 
Request-Disposition header in the request as described in RFC 3841 [56B]. 

When a SIP transaction times out, i.e. timer B, timer F or timer H expires at the UE, the UE may behave as if timer F 
expired, as described in subclause 5.1.1.4 , or subclause 5.1.1.4A as appropriate to the authentication mechanism in use . 
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NOTE 9: It is an implementation option whether these actions are also triggered by other means. 

The UE may use non-international formats of E. 164 addresses, including geo-local numbers and home-local numbers, 
in the Request-URI. 

NOTE 10: The way how the UE defines the default network for the numbers in a non-international format is 
implementation specific. 

NOTE 1 l:The way how the UE process the dial-string and handles special characters (e.g. pause) in order to 
produce a conformant SIP URI or tel URI according to RFC 3966 [22] is implementation specific. 

NOTE 12:Home operator's local policy can define a prefix string(s) to enable subscribers to differentiate dialling a 
geo-local number and/or a home-local number. 

When the UE uses home-local number, the UE shall include in the "phone-context" parameter the home domain name 
in accordance with RFC 3966 [22]. 

When the UE uses geo-local number, the UE shall: 

if access technology information available to the UE (i.e., the UE can insert P-Access-Network-lnfo header into 
the request), include the access technology information in the "phone-context" parameter according to 
RFC 3966 [22] as defined in subclause 7.2A.10; and 

if access technology information is not available to the UE (i.e., the UE cannot insert P-Access-Network-lnfo 
header into the request), include in the "phone-context" parameter the home domain name prefixed by the "geo- 
local." string according to RFC 3966 [22]as defined in subclause 7.2A.10. 

NOTE 13: The "phone-context" parameter value can be entered by the subscriber, or can be inserted by the UE, 
based on implementation. 

5.1.2A.2 UE-terminating case 

The procedures of this subclause are general to all requests and responses, except those for the REGISTER method. 

If a security association exists, the UE shall discard any SIP request that is not integrity protected and is received from 
the P-CSCF outside of the registration and authentication procedures. The requirements on the UE within the 
registration and authentication procedures are defined in subclause 5.1.1. 

If an initial request contains an Accept-Contact header field containing the g.3gpp.icsi-ref feature tag with an ICSI value 
a sip.app subtype feature tag the UE should invoke the IMS application that is the best match for the ICSI value and if 
included lARI value contained in the sip.app subtype feature tag . 

If an initial request contains an Accept-Contact header field containing the g.3gpp.iari-ref feature tag with a lARI value 
the UE should invoke the IMS application that is the best match for the lARI value. 

The UE can receive multiple ICSI values. lARl values or both in a Accept-Contact header field. In this case it is up to 
the implementation which of the multiple ICSI values or lARl values the UE takes action on. 

The UE can receive multiple Accept Contact header fields containing sip.app subtype feature tags. In this case it is up 
to the implementation which of the multiple ICSI values or lARI values it takes action on. 

NOTE 1: The application verifies that the contents of the request (e.g. SDP media capabihties, Content-Type 
header field) are consistent with the the ICSI value in the g.3gpp.icsi-ref feature tag and lARI value 
contained in the g.3gpp.iariappref feature tag. 

If an initial request does not contain an Accept-Contact header field containing a g.3gpp.icsi-ref feature tag or a 
g.3gpp.iari-ref feature tag the UE shall invoke the application that is the best match based on the contents of the request 
(e.g. SDP media capabilities, Content-Type header field, feature tag). 

The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance with 
RFC 3323 [33], and the additional requirements contained within RFC 3325 [34]. 

NOTE 1 : In the UE-terminating case, this version of the document makes no provision for the UE to provide an 
P-Preferred-Identity in the form of a hint. 
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NOTE 2: A number of headers can reveal information about the identity of the user. Where, privacy is required, 
implementers should also give consideration to other headers that can reveal identity information. 
RFC 3323 [33] subclause 4.1 gives considerations relating to a number of headers. 

If the response includes a Contact header, and the response is sent within an existing dialog, and the Contact address 
previously used in the dialog was a GRUU, then the UE should insert the previously used GRUU value in the Contact 
header as specified in draft-ietf-sip-gruu [93]. 

If the response includes a Contact header, and the response is not sent within an existing dialog, then the UE should 
populate the Contact header as follows: 

1) if a public GRUU value (pub-gruu) has been saved associated with the public user identity from the 
P-Called-Party-ID header, and the UE does not indicate privacy of the P-Asserted-ldentity, then insert the pubUc 
GRUU (pub-gruu) value in the Contact header as specified in draft-ietf-sip-gruu [93];-er 

2) if a temporary GRUU value (temp-gruu) has been saved associated with the public user identity from the 
P-Called-Party-ID header, and the UE does indicate privacy of the P-Asserted-ldentity, then the UE should insert 
the temporary GRUU (temp-gruu) value in the Contact header as specified in draft-ietf-sip-gruu [93];-er 

NOTE 3: The above items 1 and 2 are mutually exclusive. 

3) if the request is related to an IMS communication service that requires the use of an ICSl then the UE shall 
include in a g.3gpp.icsi-ref feature tag as defined in subclause 7.9.2 and RFC 3841 [56B] sip.app subtype feature 
tag the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service and may 
include the lARI value for the IMS application, (coded as specified in subclause 7.2A.9.2), that is related to the 
request in a g.3gpp.iari-ref feature tag as defined in subclause 7.9.3 according to draft rosenberg sip app media 
tag [120] and RFC 3841 [56B]. The UE may also include other ICSI values that the UE is prepared to use for all 
dialogs with the originating UE(s) and other lARI values for the IMS application that is related to the IMS 
communication service that the UE is prepared to use ; ander 

4) if the request is related to an IMS application that is supported by the UE when the use of an ICSI is not needed, 
then may include the lARl value (coded as specified in subclause 7.2A.9.2). that is related to any the to the IMS 
application and that applies for the dialog, in a g.3gpp.iari-ref feature tag as defined in subclause 7.9.3 , according 
to draft rosenberg sip app media tag [120] and RFC 38'! 1 [56B] . 

NOTE 4: The above items 3 and 4 are mutually exclusive. 

After the dialog is established the UE may change the dialog capabilities (e.g. add a media or request a supplementary 
service) if defined for the IMS communication service as identified by the ICSI value using the same dialog. Otherwise, 
the UE shall initiate a new initial request to the other user. 

If the UE did not insert a GRUU in the Contact header, then the UE shall include the protected server port in the address 
in the Contact header. 

If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall 
insert a P-Access-Network-Info header into any response to a request for a dialog, any subsequent request (except 
CANCEL requests) or response (except CANCEL responses) within a dialog or any response to a standalone method 
(see subclause 7.2A.4). 

5.1.3.1 Initial INVITE request 

Upon generating an initial INVITE request, the UE shall include the Accept header with "application/sdp", the MIME 
type associated with the 3GPP IMS XML body (see subclause 7.6. 1) and any other MIME type the UE is willing and 
capable to accept. 

The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the 
precondition mechanism" and is defined in RFC 3312 [30] as updated by RFC 4032 [64]. 

The preconditions mechanism should be supported by the originating UE. 

The UE may initiate a session without the precondition mechanism if the originating UE does not require local resource 
reservation. 

NOTE 1: The originating UE can decide if local resource reservation is required based on e.g. application 
requirements, current access network capabihties, local configuration, etc. 
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In order to allow the peer entity to reserve its required resources, an originating UE supporting the precondition 
mechanism should make use of the precondition mechanism, even if it does not require local resource reservation. 

Upon generating an initial INVITE request using the precondition mechanism, the UE shall: 

- indicate the support for reliable provisional responses and specify it using the Supported header mechanism;and 

- indicate the support for the preconditions mechanism and specify it using the Supported header mechanism. 

Upon generating an initial INVITE request using the precondition mechanism, the UE should not indicate the 
requirement for the precondition mechanism by using the Require header mechanism 

NOTE 2: If an UE chooses to require the precondition mechanism, i.e. if it indicates the "precondition" option tag 
within the Require header, the interworking with a remote UE, that does not support the precondition 
mechanism, is not described in this specification. 

NOTE 3: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261 [26]. The UE can 
accept or reject any of the forked responses, for example, if the UE is capable of supporting a limited 
number of simultaneous transactions or early dialogs. 

Upon successful reservation of local resources the UE shall confirm the successful resource reservation (see 
subclause 6.1.2) within the next SIP request. 

NOTE 4: In case of the precondition mechanism being used on both sides, this confirmation will be sent in either a 
PRACK request or an UPDATE request. In case of the precondition mechanism not being supported on 
one or both sides, alternatively a relNVITE request can be used for this confirmation, in case the 
terminating UE does not support the PRACK request (as described in RFC 3262 [27J) and does not 
support the UPDATE request (as described in RFC 3311 [29]). 

If the UE wishes to receive early media authorization indications, as described in RFC 5009 [109], it shall add the P- 
Early-Media header with the "supported" parameter to the INVITE request. 

NOTE 5 : If the UE supports the P-Early-Media header, upon receiving a 18x provisional response with a P-Early- 
Media header indicating authorized early media, as described in draft-ejzak-sipping-p-em-auth [109], if 
the preconditions are met, the UE should, based on local configuration, present received early media to 
the user. 

NOTE 6: If the UE supports the P-Early-Media header, upon receiving a 180 (Ringing) provisional response with a 
P-Early-Media header indicating authorized early media, as described in draft-ejzak-sipping-p-em- 
auth [109], if the preconditions are met, and the UE presents the received early media to the user based on 
local configuration, the UE will should not provide an indication that the invited user is being 
alerted g enerate a local ringing tone . 

NOTE 7: If the UE supports the P-Early-Media header and if the most recently received P-Early-Media header 
within the dialog includes a parameter applicable to media stream with value "inactive", then based on 
local configuration, the UE will provide an indication that the invited user is being alerted and stop 
presenting received early media to the user if requested by any previous receipt of P-Early-Media header 
within the dialog. 

If the UE wishes to receive early media authorization indications, as described in draft ejzak sipping p em auth [109], it 
shall add the P Early Media header to the INVITE request. 

When a final answer is received for one of the early dialogues, the UE proceeds to set up the SIP session. The UE shall 
not progress any remaining early dialogues to established dialogs. Therefore, upon the reception of a subsequent final 
200 (OK) response for an INVITE request (e.g., due to forking), the UE shall: 

1) acknowledge the response with an ACK request; and 

2) send a BYE request to this dialog in order to terminate it. 

Upon receiving a 488 (Not Acceptable Here) response to an initial INVITE request, the originating UE should send a 
new INVITE request containing SDP according to the procedures defined in subclause 6.1. 

NOTE 6: An example of where a new request would not be sent is where knowledge exists within the UE, or 

interaction occurs with the user, such that it is known that the resulting SDP would describe a session that 
did not meet the user requirements. 
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Upon receiving a 421 (Extension Required) response to an initial INVITE request in which the precondition mechanism 
was not used, including the "precondition" option tag in the Require header, the originating UE shall: 

- send a new INVITE request using the precondition mechanism, if the originating UE supports the precondition 
mechanism; and 

- send an UPDATE request as soon as the necessary resources are available and a 200 (OK) response for the first 
PRACK request has been received. 

Upon receiving a 503 (Service Unavailable) response to an initial INVITE request containing a Retry-After header, then 
the originating UE shall not automatically reattempt the request until after the period indicated by the Retry- After 

header contents. 

In the event the UE receives a 380 (Alternative Service) response to an INVITE request the response containing a P- 
Asserted-Identity header field with a value equal to the value of the last entry on the Path header field value received 
during registration and the response containing a 3GPP IM CN subsystem XML body as described in subclause 7.6 that 
includes an <alternative service> element with the <type> child element set to "emergency", the UE shall attempt an 
emergency call as described in subclause 5.1.6. 

NOTE 7: The last entry on the Path header field value received during registration is the value of the SIP URI of 
the P-CSCF. 

5.1 .6.2 Initial emergency registration 

When the user initiates an emergency call, if emergency registration is needed, the UE shall perform an emergency 
registration prior to sending the SIP request related to the emergency call. 

IP-CAN procedures for emergency registration are defined in 3GPP TS 23.167 |4B| and in each access teclinology 
specific annex. 

When a UE performs an initial emergency registration the UE shall perform the actions as specified in subclause 5.1.1.2 
with the following additions: 

the UE shall populate the To and From header in the REGISTER request with the emergency pubUc user identity 

as specified in 3GPP TS 23.003 [3]. 

When the UE performs an initial emergency registration and whilst this emergency registration is active, the UE shall: 

- handle the emergency registration independently from any other ongoing registration to the IM CN subsystem; 

handle any signalling or media related IP-CAN for the purpose of emergency calls independently from any other 
established IP -CAN for IM CN subsystem related signalling or media; and 

- handle all SIP signalling and all media related to the emergency call independently from any other ongoing IM 
CN subsystem signalling and media. 

5.1.6.8.1 General 

The UE shall translate any user indicated emergency number as specified in 3GPP TS 22.101 [lA] to an emergency 
service URN, i.e. a service URN with a top-level service type of "sos" service type as specified in draft-ietf-ecrit- 
service-urn [69]. An additional sub-service type can be added if information on the type of emergency service is known. 

In the event the UE receives a 380 (Alternative Service) response to an INVITE request the response containing a 3 GPP 
XML body that includes an <alternative service> element with the <type> child element set to "emergency", the UE 
shall automatically send an ACK request to the P-CSCF as per normal SIP procedures and terminate the session. In 
addition, if the 380 (Alternative Service) response includes a P-Asserted-Identity header field with a value equal to the 
value of the last entry on the Path header field value received during registration one of subclause 5.1.6.8.3 or 
subclause 5.1.6.8.4 applies. 

NOTE 1 : The UE can attempt an emergency call setup according to the procedures described in 
3GPP TS 21.008 [8]. 

NOTE 21: Emergency numbers which the UE does not detect, will be treated as a normal call. 
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NOTE 2: The last entry on the Path header field value received during registration is the value of the SIP URI of 
the F-CSCF. 

5.1 .6.8.3 Emergency session set-up within an emergency registration 

After a successful initial emergency registration, the UE shall apply the procedures as specified in subclause 5.1.2A, 
5.1.3 and 5.1.4 with the following additions: 

1) the UE shall insert in the INVITE request, a From header that includes the emergency pubUc user identity or the 
tel URI associated with the emergency public user identity, as described in subclause 4.2; 

42) the UE shall include a Request URI in the INVITE request that contains an emergency service URN, i.e. a 
service URN with a top-level service type of "sos" as specified in draft-ietf-ecrit-service-urn [69]. An additional 
sub-service type can be added if information on the type of emergency service is known; 

23) the UE shall insert in the INVITE request, a To header with: 

- the same emergency service URN as in the Request URI; or 

- if the UE cannot perform local dialstring interpretation for the dialled digits, a dialstring URI representing the 
dialled digits in accordance with RFC 4967 [103] or a tel URL representing the dialled digits; 

NOTE 1: This version of this document does not provide any specified handling of a URI with the dialled digits in 
accordance with RFC 4967 [103] at an entity within the IM CN susbsystem. Behaviour when this is used 

is therefore not defined. 

3) the UE shall insert in the INVITE request, a From header that includes the emergency pubhc user identity or the 
tel URI associated with the emergency public user identity, as described in subclause 4 .2; 

4) if available to the UE, and if defined for the access type as specified in subclause 7.2A.4, the P-Access-Network- 
Info header shall contain a location identifier such as the cell id, hne id or the identity of the I-WLAN access 
node, which is relevant for routeing the emergency call; 

NOTE 2: 3GPP TS 23.167 [4B1 describes several methods how the UE can get its location information from the 
access network or from a server. Such methods are not in the scope of this specification. 

45) the UE shall insert in the INVITE request, a P-Preferred-Identity header that includes the emergency public user 
identity or the tel URI associated with the emergency public user identity as described in subclause 4.2; 

56) if the UE has its location information available, it shall include it in the INVITE request in the following way: 

- if the UE is aware of the URI that points to where the UE's location is stored, include the URI in the 
Geolocation header in accordance with draft-ietf-sip-location-conveyance [89]; or 

- if the geographical location information of the UE is available to the UE, include its geographical location 
information as PIDF location object in accordance with RFC 4119 [90] and include the location object in a 
message body with the content type application/pidf+xml in accordance with draft-ietf-sip-location- 
conveyance [89]. The Geolocation header is set to a Content ID in accordance with draft-ietf-sip-location- 
conveyance [891; and 

NOTE 33: It is suggested that UE's only use the option of providing a URI when the domain part belongs to the 
current P-CSCF or S-CSCF provider. This is an issue on which the network operator needs to provide 
guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call is 
not desirable. 

67) if the UE has no geographical location information available, the UE shall not include any geographical location 
information as specified in draft-ietf-sip-location-conveyance [89] in the INVITE request.^aHd 

7) if available to the UE, the P Access Network Info header shall contain a location identifier such as the cell id, 
line id or the identity of the 1 WLAN access node, which is relevant for routeing the IMS emergency call. 

NOTE 3: The IMS emergency specification in 3GPP TS 23.167 ['IB] describes several methods how the UE can get 
its location information from the access network or from a server. Such methods are not in the scope of 
this specification. 
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NOTE 4: RFC 3261 [26] provides for the use of the Priority header field with a suggested value of "emergency". It 
is not precluded that emergency sessions contain this value, but such usage will have no impact on the 
processing within the IM CN subsystem. 

Upon receiving a 380 (Alternative Service) response to the INVITE request, with a P-Asserted-Identity header field 
with a value equal to the value of the last entry on the Path header field value received during registration, and the 380 
(Alternative Service) response including a IM CN subsystem XML body, with the type element set to "emergency" and 
the action element set to "emergency-registration" the UE shall: 

perform an initial emergency regislralion using a different VPLMN if available, as described in subclause 5.1.6.2 
and if the new emergency registration succeeded, attempt an emergency call as described in this subclause; 

- attempt emergency call via CS domain according to the procedures described in 3GPP TS 24.008 [81, if available 
and not already tried; or 

- perform implementation specific actions to establish the emergency caU. 

NOTE 5: The last entry on the Path header field value received during registration is the value of the SIP URI of 
the P-CSCF. 

5.1 .6.8.4 Emergency session setup within a non-emergency registration 

The UE shall apply the procedures as specified in subclauses 5.1.2A, 5.1.3 and 5.1.4 with the following additions: 

1) the UE shall include a Request URI in the INVITE request that contains an emergency service URN, i.e. a 
service URN with a top-level service type of "sos" as specified in draft-ietf-ecrit-service-um [69]. An additionjil 
sub-service type can be added if information on the type of emergency service is known; 

2) the UE shall insert in the INVITE request, a To header with: 

- the same emergency service URN as in the Request URI; or 

- if the UE cannot perform local dialstring interpretation for the dialled digits, a dialstring URI representing the 
dialled digits in accordance with RFC 4967 [103] or a tel URL representing the dialled digits; 

NOTE 1: This version of this document does not provide any specified handling of a URI with the dialled digits in 
accordance with RFC 4967 [103] at an entity within the IM CN susbsystem. Behaviour when this is used 
is therefore not defined. 

3) the UE shall insert in the INVITE request, a From header that includes the public user identity or the tel URI 
associated with the public user identity, as described in subclause 4.2; 

4) if available to the UE. and if defined for the access type as specified in subclause 7.2A.4. the P-Access-Network- 
Info header shall contain a location identifier such as the cell id, hne id or the identity of the I-WLAN access 
node, which is relevant for routeing the emergency call; 

NOTE 2: 3GPP TS 23.167 [4B] describes several methods how the UE can get its location information from the 
access network or from a server. Such methods are not in the scope of this specification. 

54) the UE shall insert in the INVITE request a P-Preferred-Identity that includes the public user identity or the tel 
URI associated with the public user identity as described in subclause 4.2; 

65) if the UE has its location information available, it shall include it in the INVITE request in the following way: 

- if the UE is aware of the URI that points to where the UE's location is stored, include the URI in the 
Geolocation header in accordance with draft-ietf-sip-location-conveyance [89]; or 

if the geographical location information of the UE is available to the UE. include its geographical location 
information as PIDF location object in accordance with RFC 4119 [90] and include the location object in a 
message body with the content type application/pidf+xml in accordance with draft-ietf-sip-location- 
conveyance [89]. The Geolocation header is set to a Content ID in accordance with draft-ietf-sip-location- 

conveyance [891; and 

6) if available to the UE, the P Access Network Info header shall contain a location identifier such as the cell id, 
hne id or the identity of the I WLAN access node, which is relevant for routeing the IMS emergency call; and 
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7) if the UE has no geographical location information available, the UE shall not include any geographical location 
information as specified in draft-ietf-sip-location-conveyance [89] in the INVITE request. 

NOTE 33: It is suggested that UE's only use the option of providing a URI when the domain part belongs to the 
current P-CSCF or S-CSCF provider. This is an issue on which the network operator needs to provide 
guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call is 
not desirable. 

8) if a public GRUU value (pub-gruu) has been saved associated with the public user identity to be used for this 
request, and the UE does not indicate privacy of the P-Asserted-Identity. then insert the public GRUU (pub- 
gruu) value in the Contact header as specified in draft-ietf-sip-gruu [931; otherwise the UE shall include the 
protected server port in the address in the Contact header. 

Upon receiving a 380 (Alternative Service) response to the INVITE request, with a P-Asserted-Identity header field 
with a value equal to the value of the last entry on the Path header field received during registration, and with the 380 
(Alternative Service) response include a IM CN subsystem XML body, with the type element set to "emergency" and 
the action element set to "emergency-registration" the UE shall: 

1) perform an initial emergency registration, as described in subclause 5.1.6.2; and 

2) attempt an emergency call as described in subclause 5.1.6.8.3. 

perform an initial emergency registration, as described in subclause 5. 1.6.2 and attempt an emergency call as 
described in subclause 5.1.6.8.3; 

attempt emergency call via CS domain according to the procedures described in 3GPP TS 24.008 [81, if available 
and not already tried; or 

perform implementation specific actions to establish the emergency call. 

Editor's Note: It is FES how the UE will indicate if no location is available if the UE does not support draft-ietf-sip- 
location-conveyance [891. 

NOTE 3: The IMS emergency specification in 3GPP TS 23.167 ['IBI describes several methods how the UE can get 
its location information from the access network or from a server. Such methods are not in the scope of 
this specification. 

NOTE 4: RFC 3261 [261 provides for the use of the Priority header field with a suggested value of "emergency". It 
is not precluded that emergency sessions contain this value, but such usage will have no impact on the 
processing within the IM CN subsystem. 

NOTE 5: The last entry on the Path header field value received during registration is the value of the SIP URI of 
the P-CSCF. 

5.2.1 General 

Subclause 5.2.2 through subclause 5.2.9 define P-CSCF procedures for SIP that do not relate to emergency. All SIP 
requests are first screened according to the procedures of subclause 5.2.10 to see if they do relate to an emergency. 

The P-CSCF shall support the Path and Service-Route headers. 

NOTE 1: The Path header is only applicable to the REGISTER request and its 200 (OK) response. The 
Service-Route header is only applicable to the 200 (OK) response of REGISTER request. 

When the P-CSCF sends any request or response to the UE, before sending the message the P-CSCF shall: 

remove the P-Charging-Function- Addresses and P-Charging- Vector headers, if present. 

When the P-CSCF receives any request or response from the UE, the P-CSCF shall: 

remove the P-Charging-Function- Addresses and P-Charging-Vector headers, if present. Also, the P-CSCF shall 
ignore any data received in the P-Charging-Function-Addresses and P-Charging-Vector headers; 

may insert previously saved values into the P-Charging-Function- Addresses and P-Charging- Vector headers 
before forwarding the message. 
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NOTE 2: When the P-CSCF is located in the visited network, then it will not receive the P-Charging-Function- 
Addresses header from the S-CCF, IBCF, or I-CSCF. Instead, the P-CSCF discovers charging function 
addresses by other means not specified in this document. 

- remove any P- Access-Network-Info header if such header contains a "network-provided" parameter; and 

- if the P-CSCF has access to a NASS supporting the UE, and the request is not an ACK request or CANCEL 
request or CANCEL response, add a P-Access-Network-Info header field that contains the "network-provided" 
parameter, and include other parameters in the P-Access-Network-Info header in accordance with the 
information received from the NASS. 

NOTE 2A: Addition of the P- Access-Network-Info header by proxies, and repetition of the P-Access-Network- 
Info header within the same request or response, requires an update to RFC 3455 before such usage is 
valid. 

When the P-CSCF receives any request or response containing the P-Media-Authorization header, the P-CSCF shall 
remove the header. 

NOTE 3: When a security association was set up at registration , the P-CSCF will integrity protect all SIP messages 
sent to the UE outside of the registration and authentication procedures by using a the security association. 
When a security association was set up at registration , the P-CSCF will discard any SIP message that is 
not protected by using athe security association and is received outside of the registration and 
authentication procedures. The integrity and confidentiality protection and checking requirements on the 
P-CSCF within the registration and authentication procedures are defined in subclause 5.2.2. 

In case IPsec is employed as security mechanism and an IPsec security association is established and the UE has 
requested symmetric response routing via an "rport" parameter in the topmost Via header field, in accordance with 
RFC 3581 r56A1, the P-CSCF shall use the ports used for establishing the IPsec security association to forward 
responses, i.e. the P-CSCF shall ignore the request for symmetric response routeing. 

For each registration, the P-CSCF determines the type of access security to apply: 

if the initial REGISTER contains the Security-Client header field, the P-CSCF shall behave as specified in 
subclause 5.2.2; 

otherwise, the P-CSCF shall behave as specified in subclause 5.2.2A . 

With the exception of 305 (Use Proxy) responses, the P-CSCF shall not recurse on 3xx responses. 

NOTE A: If the P CSCF is connected to a PDF the requirements for this interconnection is specified in the Release 
6 version of this specification. 

When the P-CSCF receives a SIP request or SIP response containing the P-Early-Media header, the P-CSCF may add, 
remove, or modify, the header depending on whether media will be allowed to traverse to/from the UE at the point 
when the header is received. 

NOTE §4: The P-CSCF can use the header for the gate control procedures, as described in 3GPP TS 29.214 1 13D]. 

In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT controlled 
by the P-CSCF, the P-CSCF may need to modify the SIP contents according to the procedures described in annex F. In 
case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT not 
controlled by the P-CSCF, the P-CSCF may need to modify the SIP contents according to the procedures described in 
annex K if both a reg-id and instance ID parameter are present in the received contact header as described in 
draft-ieft-outbound [92]. 

5.2.2 Registration (with security association set-up) 

The P-CSCF shall be prepared to receive only the initial REGISTER requests on the SIP default port values as specified 
in RFC 3261 [26]. The P-CSCF shall also be prepared to receive only the initial REGISTER requests on the port 
advertised to the UE during the P-CSCF discovery procedure. 

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall: 

1) insert a Path header in the request including an entry containing: 
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- the SIP URI identifying the P-CSCF; 

an indication that requests routed in this direction of the path (i.e. from the S-CCF towards the P-CSCF) are 
expected to be treated as for the UE-terminating case. This indication may e.g. be in a parameter in the URI, 
a character string in the user part of the URI, or be a port number in the URI; 

2) insert a Require header containing the option tag "path"; 

3) insert a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17] and a 
type 1 orig-ioi parameter. The P-CSCF shall set the type 1 orig-ioi parameter to a value that identifies the 
sending network of the request. The P-CSCF shall not include the type 1 term-ioi parameter; 

4) insert the parameter "integrity-protected" (described in subclause 7.2A.2) with a value "yes" into the 
Authorization header field in case the REGISTER request was either received protected with the security 
association created during an ongoing authentication procedure and includes an authentication challenge 
response (i.e. RES parameter), or it was received on the security association created during the last successful 
authentication procedure and with no authentication challenge response (i.e. no RES parameter), otherwise insert 
the parameter with the value "no"; 

5) in case the REGISTER request was received without protection, then check the existence of the 
Security-Client header. If the header is present, then remove and store it. If the header is not present, then the 
P-CSCF shall return a suitable 4xx response; 

6) in case the REGISTER request was received protected, then the P-CSCF shall: 

a) check the security association which protected the request. If the security association is a temporary one, then 
the request is expected to contain a Security-Verify header in addition to a Security-Client header. If there are 
no such headers, then the P-CSCF shall return a suitable 4xx response. If there are such headers, then the 
P-CSCF shall compare the content of the Security- Verify header with the content of the Security-Server 
header sent earlier and the content of the Security-Client header with the content of the Security-Client 
header received in the challenged REGISTER. If those do not match, then there is a potential man-in-the- 
middle attack. The request should be rejected by sending a suitable 4xx response. If the contents match, the 
P-CSCF shall remove the Security- Verify and the Security-Client header; 

b) if the security association the REGISTER request was received on, is an already established one, then: 

- the P-CSCF shall remove the Security- Verify header if it is present; 

- a Security-Client header containing new parameter values is expected. If this header or any required 
parameter is missing, then the p-CSCF shall return a suitable 4xx response; 

- the p-CSCF shall remove and store the Secmty-Client header before forwarding the request to the 
S-CCF; and 

c) check if the private user identity conveyed in the Authorization header of the protected REGISTER request is 

the same as the private user identity which was previously challenged or authenticated. If the private user 
identities are different, the p-CSCF shall reject the REGISTER request by returning a 403 (Forbidden) 
response; 

7) insert a P-Visited-Network-ID header field, with the value of a pre-provisioned string that identifies the visited 
network at the home network; 

8) if the p-CSCF is located in the visited network, and local policy requires the application of IBCF capabihties in 
the visited network towards the home network, forward the request to an IBCF in the visited network 

If the selected exit point: 

- does not respond to the REGISTER request and its retransmissions by the P-CSCF; or 

- sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request; 

the p-CSCF shall select a new exit point and forward the original REGISTER request. 

NOTE 1 : The list of the exit points can be either obtained as specified in RFC 3263 [27 A] or provisioned in the 
P-CSCF. 
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If the P-CSCF fails to forward the REGISTER request to any exit point, the P-CSCF shall send back a 504 
(Server Time-Out) response to the user, in accordance with the procedures in RFC 3261 [26] unless local policy 
allows omitting the exit point; and 

NOTE 2: If the P-CSCF forwards the request to an IBCF in the visited network, the IBCF can determine the entry 
point of the home network, using the same mechanisms as described in note 1 above. In that case the 
P CSCF does not need to determine the entry point of the home network. 

9) if the P-CSCF is located in the visited network and local policy does not require the application of IBCF 
capabilities in the visited network towards the home network, determine the entry point of the home network and 
forward the request to that entry point. 

If the selected entry point: 

- does not respond to the REGISTER request and its retransmissions by the P-CSCF; or 

- sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request; 

the P-CSCF shall select a new entry point and forward the original REGISTER request. 

NOTE 3: The list of the entry points can be either obtained as specified in RFC 3263 [27 A] or provisioned in the 
P-CSCF. 

If the P-CSCF fails to forward the REGISTER request to any entry point, the P-CSCF shall send back a 504 
(Server Time-Out) response to the user, in accordance with the procedures in RFC 3261 [261 ; and v 

10) if the P-CSCF is located in the home network, determine the I-CSCF of the home network and forward the 
request to that I-CSCF. 

If the selected I-CSCF: 

- does not respond to the REGISTER request and its retransmissions by the P-CSCF; or 

- sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request; 
the P-CSCF shall select a new I-CSCF and forward the original REGISTER request. 

NOTE 3A: The hst of the I-CSCFs can be either obtained as specified in RFC 3263 [27 A] or provisioned in the P- 
CSCF. 

If the P-CSCF fails to forward the REGISTER request to any 1-CSCF. the P-CSCF shall send back a 504 (Server 
Time-Out) response to the user, in accordance with the procedures in RFC 3261 [261. 

When the P-CSCF receives a 401 (Unauthorized) response to a REGISTER request, the P-CSCF shall: 

1) delete any temporary set of security associations established towards the UE; 

2) remove the CK and IK values contained in the 401 (Unauthorized) response and bind them to the proper private 
user identity and to the temporary set of security associations which will be setup as a result of this challenge. 
The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the CK and IK have been 
removed; 

3) insert a Security-Server header in the response, containing the P-CSCF static security list and the parameters 
needed for the security association setup, as specified in annex H of 3GPP TS 33.203 [19]. The P-CSCF shall 
support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the 
IPsec layer algorithms for integrity and confidentiality protection as defined in 3GPP TS 33.203 [19] and shall 
announce support for them according to the procedures defined in RFC 3329 [48]; 

4) set up the temporary set of security associations with a temporary SIP level lifetime between the UE and the 
P-CSCF for the user identified with the private user identity. For further details see 3GPP TS 33.203 [19] and 
RFC 3329 [48]. The P-CSCF shall set the temporary SIP level lifetime for the temporary set of security 
associations to the value of reg-await-auth timer; and 

5) send the 401 (Unauthorized) response to the UE using the security association with which the associated 
REGISTER request was protected, or improtected in case the REGISTER request was received unprotected. 



ETSI 



Release 7 



47 



ETSI TS 124 503 V8.6.0 (2009-09) 



NOTE 4: The challenge in the 401 (Unauthorized) response sent back by the S-CCF to the UE as a response to the 
REGISTER request is piggybacked by the P-CSCF to insert the Security-Server header field in it. The 
S-CCF authenticates the UE, while the P-CSCF negotiates and sets up two pairs of security associations 
with the UE during the same registration procedure. For further details see 3GPP TS 33.203 [19]. 

When the P-CSCF receives a 200 (OK) response to a REGISTER request, the P-CSCF shall check the value of the 
Expires header field and/or Expires parameter in the Contact header. When the value of the Expires header field and/or 
expires parameter in the Contact header is different than zero, then the P-CSCF shall: 

1) save the list of Service-Route headers preserving the order. The P-CSCF shall store this list during the entire 
registration period of the respective public user identity. The P-CSCF shall use this list to validate the routeing 
information in the requests originated by the UE. If this registration is a reregistration, the P-CSCF shall replace 
the already existing list of Service-Route headers with the new list; 

2) associate the Service-Route header list with the registered public user identity; 

3) store the public user identities and wildcarded public user identities , found in the P-Associated-URI header 
value, including any associated display names, and associate them to the registered public user identity, i.e. the 
registered public user identity and its associated set of implicitly registered public user identities and impUcitlv 
registered wildcarded public user identities ; 

4) store the default public user identity, including its associated display name, if provided, for use with procedures 
for the P-Asserted-Identity header. The default public user identity is the first on the list of URIs present in the P- 
Associated-URI header; 

NOTE 5: There can be more than one default public user identity stored in the P-CSCF, as the result of the multiple 
registrations of public user identities. 

5) store the values received in the P-Charging-Function-Addresses header; 

6) if a term-ioi parameter is received in the P-Charging- Vector header, store the value of the received term-ioi 

parameter; 

NOTE 6: Any received term-ioi parameter will be a type 1 term-ioi. The type 1 term-ioi identifies the home 
network of the registered user. 

7) if an existing set of security association is available, set the SIP level lifetime of the security association to the 
longest of either the previously existing security association lifetime, or the lifetime of the just completed 
registration plus 30 seconds; 

8) if a temporary set of security associations exists, change the temporary set of security associations to a newly 
established set of security associations, i.e. set its SIP level lifetime to the longest of either the previously 
existing set of security associations SIP level lifetime, or the lifetime of the just completed registration plus 
30 seconds; and 

9) protect the 200 (OK) response to the REGISTER request within the same security association to that in which 
the request was protected. 

When receiving a SIP message (including REGISTER requests) from the UE over the newly estabUshed set of security 
associations that have not yet been taken into use, the P-CSCF shall: 

1) reduce the SIP level lifetime of the old set of security associations towards the same UE to 64*T1 (if currently 
longer than 64*T1); and 

2) use the newly established set of security associations for further messages sent towards the UE as appropriate 
(i.e. take the newly established set of security associations into use). 

NOTE 7: In this case, the P-CSCF will send requests towards the UE over the newly established set of security 

associations. Responses towards the UE that are sent via UDP will be sent over the newly estabUshed set 
of security associations. Responses towards the UE that are sent via TCP will be sent over the same set of 
security associations that the related request was received on. 

NOTE 8: When receiving a SIP message (including REGISTER requests) from the UE over a set of security 

associations that is different from the newly estabUshed set of security associations, the P-CSCF wiU not 
take any action on any set of security associations. 
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When the SIP level lifetime of an old set of security associations is about to expire, i.e. their SIP level lifetime is shorter 
than 64*T1 and a newly established set of secmty associations has not been taken into use, the P-CSCF shall use the 
newly established set of security associations for further messages towards the UE as appropriate (see note 5). 

When sending the 200 (OK) response for a REGISTER request that concludes a re-authentication, the P-CSCF shall: 

1) keep the set of security associations that was used for the REGISTER request that initiated the re-authentication; 

2) keep the newly established set of security associations created during this authentication; 

3) delete, if existing, any other set of security associations towards this UE immediately; and 

4) go on using for further requests sent towards the UE the set of security associations that was used to protect the 
REGISTER request that initiated the re-authentication. 

When sending the 200 (OK) response for a REGISTER request that concludes an initial authentication, i.e. the initial 
REGISTER request was received unprotected, the P-CSCF shall: 

1) keep the newly established set of security associations created during this authentication; 

2) delete, if existing, any other set of security associations towards this UE immediately; and 

3) use the kept newly estabhshed set of security associations for further messages sent towards the UE. 

NOTE 9: The P-CSCF will maintain two Route header lists. The first Route header list - created during the 
registration procedure - is used only to validate the routeing information in the initial requests that 
originate from the UE. This list is valid during the entire registration of the respective public user identity. 
The second Route hst - constructed from the Record Route headers in the initial INVITE and associated 
response - is used during the duration of the call. Once the call is terminated, the second Route list is 
discarded. 

The P-CSCF shall delete any security association from the IPsec database when their SIP level Ufetime expires. 
The handling of the security associations at the P-CSCF is summarized in table 5.2.2-1. 



Table 5.2.2-1 : Handling of security associations at the P-CSCF 





Temporary set of security 
associations 


Newly established set of 
security associations 


Old set of security 
associations 


SIP message received over 
newly established set of 
security associations that 
have not yet been taken into 
use 


No action 


Take into use 


Reduce SIP level lifetime to 
64*11 , if lifetime is larger 
than 64*T1 


SIP message received over 
old set of security 

associations 


No action 


No action 


No action 


Old set of security 
associations currently in use 
will expire in 64*11 


No action 


Take into use 


No action 


Sending an authorization 
challenge within a 401 
(Unauthorized) response for 
a REGISTER request 


Create 

Remove any previously 
existing temporary set of 
security associations 


No action 


No action 


Sending 200 (OK) response 
for REGISTER request that 
concludes re-authentication 


Change to a newly 
established set of security 
associations 


Convert to and treat as old 
set of security associations 
(see next column) 


Continue using the old set of 
security associations over 
which the REGISTER 
request, that initiated the re- 
authentication was received. 
Delete all other old sets of 
security associations 
immediately 


Sending 200 (OK) response 
for REGISTER request that 
concludes Initial 
authentication 


Change to a newly 
established set of security 
associations and take into 
use immediately 


Convert to old set of 
security associations, i.e. 
delete 


Delete 
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5.2.2A Registration without security association set-up 

The P-CSCF shall be prepared to receive the initial REGISTER requests on the SIP default port values as specified in 
RFC 3261 f261. The P-CSCF shall also be prepared to receive the initial REGISTER requests on the port advertised to 
the UE during the P-CSCF discovery procedure. 

When the P-CSCF receives a REGISTER request fi-om the UE, the P-CSCF shall: 

1) insert a Path header in the request including an entry containing: 

- the SIP URI identifying the P-CSCF: 

an indication that requests routed in this direction of the path (i.e. from the S-CCF towards the P-CSCF) are 
expected to be treated as for the UE-terminating case. This indication may e.g. be in a parameter in the URI, 
a character string in the user part of the URI, or be a port number in the URI; 

2) insert a Require header containing the option tag "path"; 

3) insert a P-Charging-Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [ 17] and a 
type 1 orig-ioi parameter. The P-CSCF shall set the type 1 orig-ioi parameter to a value that identifies the 
sending network of the request. The P-CSCF shall not include the type 1 term-ioi parameter; 

4) insert a P-Visited-Network-ID header field, with the value of a pre-provisioned string that identifies the visited 

network at the home network; 

5) if the P-CSCF is located in the visited network, and local pohcy requires the apphcation of IBCF capabilities in 
the visited network towards the home network, forward the request to an IBCF in the visited network 

If the selected exit point: 

does not respond to the REGISTER request and its retransmissions by the P-CSCF; or 

sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request; 

the P-CSCF shall select a new exit point and forward the original REGISTER request. 

NOTE 1 : The list of the exit points can be either obtained as specified in RFC 3263 [27 A1 or provisioned in the 
P-CSCF. 

If the P-CSCF fails to forward the REGISTER request to any exit point, the P-CSCF shall send back a 408 
(Request Timeout) response or 504 (Server Timc-Out) response to the user, in accordance with the procedures in 
RFC 3261 [261 unless local pohcy allows omitting the exit point; and 

NOTE 2: If the P-CSCF forwards the request to an IBCF in the visited network, the IBCF can determine the entry 
point of the home network, using the same mechanisms as described in note 1 above. In that case the 
P-CSCF does not need to determine the entry point of the home network. 

6) determine the entry point of the home network and forward the request to that entry point. 
If the selected entry point: 

- does not respond to the REGISTER request and its retransmissions by the P-CSCF; or 

- sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request; 

the P-CSCF shall select a new entry point and forward the original REGISTER request. 

NOTE 3: The list of the entry points can be either obtained as specified in RFC 3263 [27 A1 or provisioned in the 
P-CSCF. 

If the P-CSCF fails to forward the REGISTER request to any entry point, the P-CSCF shall send back a 408 
(Request Timeout) response or 504 (Server Time-Out) response to the user, in accordance with the procedures in 
RFC 3261 [261. 

When the P-CSCF receives a 200 (OK) response to a REGISTER request, the P-CSCF shall check the value of the 
Expires header field and/or Expires parameter in the Contact header. When the value of the Expires header field and/or 
expires parameter in the Contact header is different than zero, then the P-CSCF shall: 
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1) save the list of Service-Route headers preserving the order. The P-CSCF shall store this list during the entire 
registration period of the respective public user identity. The P-CSCF shall use this list to validate the routeing 
information in the requests originated by the UE. If this registration is a reregistration, the P-CSCF shall replace 
the already existing list of Service-Route headers with the new Ust; 

2) associate the Service-Route header list with the registered public user identity; 

3) store an association between the IP source address and port of the initial REGISTER request and the public user 
identities and wildcarded public user identities, found in the P-Associated-URI header value and associate them 
to the public user identity under registration; 

4) store an association between the IP source address and port of the initial REGISTER request the default public 
user identity for use with procedures for the P-Asserted-Identity header. The default public user identity is the 
first on the list of URIs present in the P-Associated-URI header; 

NOTE 4: There can be more than one default public user identity stored in the P-CSCF, as the result of the multiple 

registrations of public user identities. 

5) store the values received in the P-Charging-Function-Addresses header; 

6) if a term-ioi parameter is received in the P-Charging- Vector header, store the value of the received term-ioi 

parameter; 

NOTE 5: Any received term-ioi parameter will be a type 1 term-ioi. The type 1 term-ioi identifies the home 
network of the registered user. 

5.2.4 Registration of multiple public user identities 

Upon receipt of a 2xx response to the SUBSCRIBE request the P-CSCF shall maintain the generated dialog (identified 

by the values of the Call-ID header , and the values of tags in To and From headers). 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package of 
the user, the P-CSCF shall perform the following actions: 

1) for each public user identity whose state attribute in the <registration> element is set to "active", i.e. registered; 
and 

- the state attribute within the <contact> sub-element is set to "active"; and 

- the value of the <uri> sub-element inside the <contact> sub-element is set to the contact address of the user's 
UE; and 

- the event attribute of that <contact> sub-element(s) is set to "registered" or "created"; 
the P-CSCF shall: 

- bind the indicated public user identity as registered to the contact information of the respective user; and 
add the public user identity to the list of the public user identities that are registered for the user; 

2) for each public user identity whose state attribute in the <registration> element is set to "active", i.e. registered: 
and 

the state attribute within the <contact> sub-element is set to "terminated"; 

- the value of the <uri> sub-element inside the <contact> sub-element is set to the contact address of the user's 
UE; and 

- the event attribute of that <contact> sub-element(s) is set to "deactivated", "expired", "probation", 
"unregistered", or "rejected"; 

the P-CSCF shall consider the indicated public user identity as deregistered for this user, and shall release all 
stored information for the pubUc user identity bound to the respective user; and 

3) for each public user identity whose state attribute in the <registration> element is set to "terminated", i.e. 
deregistered; and 
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- the value of the <uri> sub-element inside the <contact> sub-element is set to the contact address of the user's 

UE; and 

- the event attribute of that <contact> sub-element(s) is set to "deactivated", "expired", "probation", 
"unregistered", or "rejected"; 

the P-CSCF shall consider the indicated public user identity as deregistered for this UE, and shall release all 
stored information for these public user identity bound to the respective user and remove the public user identity 
from the list of the pubhc user identities that are registered for the user. 

If all public user identities, that were registered by the user using its private user identity, have been deregistered, the P- 
CSCF, will receive from the S-CSCF a NOTIFY request that may include the Subscription-State header set to 
"terminated", as described in subclause 5.4.2.1.2. If the Subscription-State header was not set to "terminated", the P- 
CSCF may either unsubscribe to the reg event package of the user or let the subscription expire. 

NOTE 1: Upon receipt of a NOTIFY request with the Subscription-State header set to "terminated", the P-CSCF 
considers the subscription to the reg event package terminated (i.e. as if the P-CSCF had sent a 
SUBSCRIBE request with an Expires header containing a value of zero). 

NOTE 2: There may be public user identities which are imphcitly registered within the registrar (S-CSCF) of the 
user upon registration of one public user identity. The procedures in this subclause provide a mechanism 
to inform the P-CSCF about these implicitly registered public user identities. 

5.2.5.1 User-initiated deregistration 

When the P-CSCF receives a 200 (OK) response to a REGISTER request (sent according to subclause 5.2.2 or 
subclause 5.2.2A ) sent by this UE, it shall check the value of the Expires header field and/or expires parameter in the 
Contact header field. When the value of the Expires header field or expires parameter equals zero, then the P-CSCF 
shall: 

1) remove the pubhc user identity found in the To header field, and all the associated public user identities, from 
the registered public user identities list belonging to this UE and all related stored information; and 

2) check if the UE has left any other registered public user identity. When all of the public user identities that were 
registered by this UE are deregistered, the P-CSCF shall delete the security associations (if present) towards the 
UE, after the server transaction (as defined in RFC 3261 [26]) pertaining to this deregistration terminates. 

NOTE 1 : Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to 
"terminated" (i.e. all public user identities are deregistered) and the Subscription-State header set to 
"terminated", the P-CSCF considers the subscription to the reg event package terminated (i.e. as if the 
P-CSCF had sent a SUBSCRIBE request with an Expires header containing a value of zero). 

NOTE 2: There is no requirement to distinguish a REGISTER request relating to a registration from that relating to 
a deregistration. For administration reasons the P-CSCF may distinguish such requests, however this has 
no impact on the SIP procedures. 

NOTE 3: When the P-CSCF has sent the 200 (OK) response for the REGISTER request of the only public user 
identity ciurently registered with its associated set of implicitly registered public user identities (i.e. no 
other is registered), the P-CSCF removes (if present) the security association estabUshed between the 
P-CSCF and the UE. Therefore further SIP signalhng (e.g. the NOTIFY request containing the 
deregistration event) will not reach the UE. 

5.2.5.2 Network-initiated deregistration 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package of 
the UE, as described in subclause 5.2.3, including one or more <registration> element(s) which were registered by the 
UE with either: 

the state attribute set to "terminated"; or 

- the state attribute set to "active" and the state attribute within the <contact> sub-element belonging to this UE set 
to "terminated", and the event attribute within the <contact> sub-element belonging to this UE set to "rejected" 
or "deactivated"; 
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the P-CSCF shall remove all stored information for these public user identities for this UE and remove these public user 
identities from the list of the public user identities that are registered for the user. 

Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" 
(i.e. all public user identities are deregistered) and the Subscription-State header set to "terminated" or when all public 
user identities of the UE have been deregistered, the P-CSCF shall shorten any existing security associations towards 
the UE. 

NOTE 1: The security association between the P-CSCF and the UE is shortened to a value that will allow the 
NOTIFY request containing the deregistration event to reach the UE. 

NOTE 2: When the P-CSCF receives the NOTIFY request with Subscription-State header containing the value of 
"terminated", the P-CSCF considers the subscription to the reg event package terminated (i.e. as if the 
P-CSCF had sent a SUBSCRIBE request to the S-CCF with an Expires header containing a value of 
zero). 

5.2.6.2 Determination of UE-originated or UE-terminated case 

Upon receipt of an initial request or a target refresh request or a stand-alone transaction, the P-CSCF shall: 

perform the procedures for the UE-terminating case as described in subclause 5.2.6.4 if the request makes use of 
the information for UE-terminating calls, which was added to the Path header entry of the P-CSCF during 
registration (see subclause 5.2.2 or subclause 5.2.2A) , e.g. the message is received at a certain port or the 
topmost Route header contains a specific user part or parameter; 

- perform the procedures for the UE-originating case as described in subclause 5.2.6.3 if this information is not 
used by the request. 

5.2.6.3 Requests initiated by the UE 

When the P-CSCF receives from the UE an initial request for a dialog or a request for a standalone transaction, and the 
request contains a P-Preferred-Identity header that matches one of the registered public user identities, or wildcarded 
public user identities the P-CSCF shall identify the initiator of the request by that public user identity. 

NOTE 1 : If no security association was set-up during registration, the P-CSCF identifies the initiator of the request 
by matching the IP source address and port of the request with the IP source address entries stored during 
the registration for which it holds the list of registered public user identities. 

When the P-CSCF receives from the UE an initial request for a dialog or a request for a standalone transaction, and the 
request contains a P-Preferred-Identity header that does not match one of the registered public user identities, or does 
not contain a P-Preferred-Identity header, the P-CSCF shall identify the initiator of the request by a default pubhc user 
identity. If there is more than one default public user identity available, the P-CSCF shall randomly select one of them. 

NOTE 2: If no security association was sel-up during rcgislration, the P-CSCF identifies tlie initiator of tlie request 
by matching the IP source address and port of the request with the IP source address entries stored during 
the registration for which it holds one or more default public user identities. 

NOTE 3-1: The contents of the From header do not form any part of this decision process. 

NOTE 43: The display-name portion of the P-Preferred-Identity header and the registered public user identities is 
not included in the comparison to determine a match. 

When the P-CSCF receives from the UE an initial request for a dialog, and a Service-Route header list exists for the 
initiator of the request, the P-CSCF shall: 

OA) remove its own SIP URI from the top of the list of Route headers; 

1) verify that the resulting list of Route headers matches the list of URIs received in the Service-Route header 
(during the last successful registration or 

re-registration). This verification is done on a per URI basis, not as a whole string. If the verification fails, then 
the P-CSCF shall either: 

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with 
the execution of steps 2 onwards; or 
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b) replace the preloaded Route header value in the request with the value of the Service-Route header received 
during the last 200 (OK) response for the last successful a-registration or reregistration; 

2) if the P-CSCF is located in the visited network, and local pohcy requires IBCF capabihties in the visited network 
towards the home network, then the P-CSCF shall select an IBCF in the visited network and add the URI of the 
selected IBCF to the topmost Route header; 

NOTE 5^: It is implementation dependent as to how the P-CSCF obtains the address of the IBCF exit point. 

3) add its own address to the Via header. The P-CSCF Via header entry is built in a format that contains the port 
number of the P-CSCF in accordance with the procedures of RFC3261 [26], and either: 

a) the P-CSCF FQDN that resolves to the IP address; or 

b) the P-CSCF IP address; 

4) when adding its own SIP URI to the top of the Record-Route header, build the P-CSCF SIP URI in a format that 
contains the port number of the P-CSCF where it awaits subsequent requests from the called party, and either: 

a) the P-CSCF FQDN that resolves to the IP address; or 

b) the P-CSCF IP address; 

5) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with a value including 
the display name if previously stored during registration representing the initiator of the request; 

6) add a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]; 

6A) if the identity of the initiator of the request was taken from P-Preferred-Identity header field by it matching a 

registered wildcarded public user identity and the P-CSCF supports the SIP P-Profile-Key private header 
extension, include the wildcarded public user identity value in the P-Profile-Key header field as defined in 
RFC 5002 [97]; 

7) if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in the 
request such that the P-CSCF is able to release the session if needed; 

before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives any Ixx or 2xx response to the above request, the P-CSCF shall: 

1) store the values received in the P-Charging-Function-Addresses header; 

2) store the list of Record-Route headers from the received response; 

3) store the dialog ID and associate it with the private user identity and public user identity involved in the session; 

4) if a security association exists, in the response rewrite its own Record Route entry to its own SIP URI that 
contains the protected server port number of the security association established from the UE to the P-CSCF and 
either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association estabUshed from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; and 

NOTE 46: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details on the selection of the protected port values see 3GPP TS 33.203 [19]. 

5) if the response corresponds to an INVITE request, save the Contact, From, To and Record-Route header field 
values received in the response such that the P-CSCF is able to release the session if needed; 

before forwarding the response to the UE in accordance with the procedures of RFC 3261 |26]. 

When the P-CSCF receives from the UE a target refresh request for a dialog, the P-CSCF shall: 

1) verify if the request relates to a dialog in which the originator of the request is involved: 
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a) if the request does not relates to an existing dialog in which the originator is involved, then the P-CSCF shall 
answer the request by sending a 403 (Forbidden) response back to the originator. The P-CSCF will not 
forward the request. No other actions are required; or 

b) if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall continue 
with the following steps; 

1 A) remove its own SIP URI from the top of the list of Route headers; 

2) verify that the resulting list of Route headers in the request matches the stored list of Record-Route headers for 
constructed by inverting the order of the stored list of Record-Route headers and removing its Record-Route 
header from the list the same dialog . This verification is done on a per URI basis, not as a whole string. If the 
verification fails, then the P-CSCF shall either: 

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with 
the execution of steps 3 onwards; or 

b) replace the Route header value in the request with the stored list of Record-Route headers constructed by 
inverting the order of the stored list of Record-Route headers and removing its Record-Route header from the 
list for the same dialog ; 

3) add its own address to the Via header. The P-CSCF Via header entry is built in a format that contains the port 
number of the P-CSCF where it awaits the responses to come, and either: 

a) the P-CSCF FQDN that resolves to the IP address, or 

b) the P-CSCF IP address; 

4) when adding its own SIP URI to the Record-Route header, build the P-CSCF SIP URI in a format that contains 
the port number of the P-CSCF where it awaits subsequent requests from the called party, and either: 

a) the P-CSCF FQDN that resolves to the IP address; or 

b) the P-CSCF IP address; and 

5) for INVITE dialogs (i.e. dialogs initiated by an INVITE request), replace the saved Contact and Cseq header 
filed values received in the request such that the P-CSCF is able to release the session if needed; 

NOTE S7: The replaced Contact header field value is valid only if a Ixx or 2xx response will be received for the 
request. In other cases the old value is still valid. 

before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives a Ixx or 2xx response to the above request, the P-CSCF shall: 

1) if a security association exists, rewrite the-the-address and port number of its own Record Route entry to the 
same value as for the response to the initial request for the dialog; and 

2) replace the saved Contact header value received in the response such that the P-CSCF is able to release the 
session if needed; 

before forwarding the response to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives from the UE the request for a standalone transaction, and a Service-Route header list exists 
for the initiator of the request, the P-CSCF shall: 

OA) remove its own SIP URI from the top of the list of Route headers; 

1) verify that the resulting list of Route headers matches the list of URIs received in the Service-Route header 
(during the last successful registration or re-registration) matches the preloaded Route headers in the received 
request . This verification is done on a per URI basis, not as a whole string. If the verification fails, then the 
P-CSCF shall either: 

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with 
the execution of steps 3 onwards; or 
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b) replace the preloaded Route header value in the request with the one received during the last registration in 

the Service-Route header of the 200 (OK) response; 

2) if the P-CSCF is located in the visited network, and local poUcy requires IBCF capabiUties in the visited network 
towards the home network, then the P-CSCF shall select an IBCF in the visited network and add the URI of the 
selected IBCF to the topmost Route header; 

NOTE 68: It is implementation dependent as to how the P-CSCF obtains the address of the IBCF exit point. 

3) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with a value, 
including the display name if previously stored during registration, representing the initiator of the request; and 

4) add a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]; 

4A) if the identity of the initiator of the request was taken from P-Preferred-Identity header field by it matching a 
registered wildcarded public user identity and the P-CSCF supports the SIP P-Profile-Key private header 
extension, include the wildcarded public user identity value in the P-Profile-Key header field as defined in 
RFC 5002 r971; and 

before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 
When the P-CSCF receives any response to the above request, the P-CSCF shall: 

1) store the values received in the P-Charging-Function- Addresses header; 

before forwarding the response to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives from the UE subsequent requests other than a target refresh request (including requests 
relating to an existing dialog where the method is unknown), the P-CSCF shall: 

1) verify if the request relates to a dialog in which the originator of the request is involved: 

a) if the request does not relates to an existing dialog in which the originator is involved, then the P-CSCF shall 
answer the request by sending a 403 (Forbidden) response back to the originator. The P-CSCF will not 
forward the request. No other actions are required; or 

b) if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall continue 
with the following steps; 

1 A) remove its own SIP URI from the top of the list of Route headers; 

2) verify that the resulting list of Route headers in the request matches the stored list of Record-Route headers 
constructed by inverting the order of the stored list of Record-Route headers and removing its Record-Route 
header from the list for the same dialog . This verification is done on a per URI basis, not as a whole string. If the 
verification fails, then the P-CSCF shall either: 

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with 
the execution of steps 3 onwards; or 

b) replace the Route header value in the request with the stored list of Record-Route headers constructed by 
inverting the order of the stored list of Record-Route headers and removing its Record-Route header from the 
list for the same dialog ; 

3) for dialogs that are not INVITE dialogs, add a P-Charging- Vector header with the icid parameter populated as 
specified in 3GPP TS 32.260 [17]; and 

4) for INVITE dialogs, replace the saved Cseq header value received in the request such that the P-CSCF is able to 

release the session if needed; 

before forwarding the request, (based on the topmost Route header,) in accordance with the procedures of 
RFC 3261 [26]. 

When the P-CSCF receives from the UE the request for an unknown method (that does not relate to an existing dialog), 
and a Service-Route header list exists for the initiator of the request, the P-CSCF shall: 
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1) verify that the list of URIs received in the Service-Route header (during the last successful registration or 
re-registration) is included, preserving the same order, as a subset of the preloaded Route headers in the received 
request. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the 
P-CSCF shall either: 

a) return a 400 (Bad Request) response; the P-CSCF shall not forward the request, and shall not continue with 

the execution of steps 2 onwards; or 

b) replace the Route header value in the request with the one received during the last registration in the Service- 
Route header of the 200 (OK) response; 

2) if the P-CSCF is located in the visited network, and local policy requires IBCF capabilities in the visited network 
towards the home network, then the P-CSCF shall select an IBCF in the visited network and add the URI of the 
selected IBCF to the topmost Route header; and 

NOTE 79: It is implementation dependent as to how the P-CSCF obtains the address of the IBCF exit point. 

3) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with a value, 
including the display name if previously stored during registration, representing the initiator of the request; 

3A) if the identity of the initiator of the request was taken from P-Preferred-Identity header field by it matching a 
registered wildcarded public user identity and the P-CSCF supports the SIP P-Profile-Key private header 
extension, include the vyildcarded public user identity value in the P-Profile-Key header field as defined in 
RFC 5002 [971; 

before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 
5.2.6.4 Requests terminated by the UE 

When the P-CSCF receives, destined for the UE, an initial request for a dialog, prior to forwarding the request, the 
P-CSCF shall: 

1) convert the list of Record-Route header values into a Ust of Route header values and save this list of Route 
headers; 

2) if the request is an INVITE request, save a copy of the Contact, CSeq and Record-Route header field values 
received in the request such that the P-CSCF is able to release the session if needed; 

3) when adding its own SIP URI to the top of the list of Record-Route headers and save the list, build the P-CSCF 
SIP URI in a format that contains if a security association exists the protected server port number of the security 
association established from the UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association estabUshed from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association estabUshed from the UE to the P-CSCF; 

4) when adding its own address to the top of the received list of Via header and save the list, build the P-CSCF Via 
header entry in a format that contains, if a security association exists the protected server port number of the 
security association established from the UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; 

NOTE 1 : The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details of the usage of the two ports see 3GPP TS 33.203 [19]. 

5) remove and store the values received in the P-Charging-Function-Addresses header; 

6) remove and store the icid parameter received in the P-Charging-Vector header; and 

7) save a copy of the P-Called-Party-ID header; 

before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26]. 
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When the P-CSCF receives any Ixx or 2xx response to the above request, the P-CSCF shall: 

1) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with the saved pubhc 
user identity from the P-Called-Party-ID header that was received in the request, plus the display name if 
previously stored during registration, representing the initiator of the response; 

2) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If the verification fails, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 

3) verify that the list of URIs received in the Record-Route header of the request corresponding to the same dialog 
is included, preserving the same order, as a subset of the Record-Route header list of this response. This 
verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall 
either: 

a) discard the response; or 

b) replace the Record-Route header values with those received in the request, if a security association exists add 
the port number of its own Record-Route entry with its own SIP URI with the port number where it awaits 

subsequent requests from the calling party and either: 

- the P-CSCF FQDN that resolves to its IP address; or 

- the P-CSCF IP address; and 

remove the comp parameter if present . 

If the verification is successful, the P-CSCF shall , if a security association exists, rewrite its own 
Record-Route entry to its SIP URI in a format that contains the port number where it awaits subsequent 
requests from the calling party and either: 

- the P-CSCF FQDN that resolves to its IP address; or 

- the P-CSCF IP address; and 

remove the comp parameter if present ; 

4) store the dialog ID and associate it with the private user identity and public user identity involved in the session; 
and 

5) if the response corresponds to an INVITE request, save the Contact, To, From and Record-Route header field 
value received in the response such that the P-CSCF is able to release the session if needed; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives any other response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If these lists do not match, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives, destined for the UE, a target refresh request for a dialog, prior to forwarding the request, 
the P-CSCF shall: 

1) add its own address to the top of the received list of Via header and save the list. The P-CSCF Via header entry 
is built in a format that contains if a security association exists, t he protected server port number of the security 
association established from the UE to the P-CSCF and either: 
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a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 

P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; 

NOTE 2: The P-CSCF associates two ports, a protected cUent port and a protected server port, with each pair of 
security associations. For details of the usage of the two ports see 3GPP TS 33.203 [19]. 

2) when adding its own SIP URI to the top of the hst of Record-Route headers and save the list, build the P-CSCF 
SIP URI in a format that contains if a security association exists, the protected server port number of the security 
association established from the UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; and 

3) for INVITE dialogs, replace the saved Contact and Cseq header field values received in the request such that the 
P-CSCF is able to release the session if needed; 

NOTE 3: The replaced Contact header field value is valid only if a Ixx or 2xx response will be received for the 
request. In other cases the old value is still valid. 

Before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26J. 

When the P-CSCF receives a Ixx or 2xx response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved Ust of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If the verification fails, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 

2) if a security association exists, rewrite the address and port number of its own Record-Route entry to the same 
value as for the response to the initial request for the dialog and remove the comp parameter; and 

3) replace the saved Contact header field value received in the response such that the P-CSCF is able to release the 
session if needed; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 
When the P-CSCF receives any other response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved Ust of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If the verification fails, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; and 

2) if a security association exists, rewrite the IP address and the port number of its own Record-Route entry to the 
IP address and the port number where it awaits subsequent requests from the calling party and remove the comp 
parameter if present ; 

before forwarding the response in accordance with the procedures of RFC 3261 |26|. 

When the P-CSCF receives, destined for the UE, a request for a standalone transaction, or a request for an unknown 
method (that does not relate to an existing dialog), prior to forwarding the request, the P-CSCF shall: 

1) add its own address to the top of the received Ust of Via header and save the list. The P-CSCF Via header entry 
is built in a format that contains if a security association exists, the protected server port number of the security 
association established from the UE to the P-CSCF and either: 
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a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 

P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; 

NOTE 4: The P-CSCF associates two ports, a protected cUent port and a protected server port, with each pair of 
security associations. For details of the usage of the two ports see 3GPP TS 33.203 [19]. 

2) store the values received in the P-Charging-Function- Addresses header; 

3) remove and store the icid parameter received in the P-Charging- Vector header; and 

4) save a copy of the P-CaUed-Party-ID header; 

before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26]. 
When the P-CSCF receives any response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If these lists do not match, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; and 

2) remove the P-Preferred-ldentity header, if present, and insert an P-Asserted-ldentity header with the saved public 
user identity from the P-Called-Party-ID header of the request, plus the display name if previously stored during 
registration, representing the initiator of the response; 

before forwarding the response in accordance with the procedures of RFC 3261 |26J. 

When the P-CSCF receives, destined for the UE, a subsequent request for a dialog that is not a target refresh request 
(including requests relating to an existing dialog where the method is unknown), prior to forwarding the request, the 
P-CSCF shaU: 

1) add its own address to the top of the received list of Via header and save the list The P-CSCF Via header entry is 
built in a format that contains if a securitv association exists, the protected server port number of the secmity 
association established from the UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; 

NOTE 5: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details of the usage of the two ports see 3GPP TS 33.203 [19]. 

2) remove and store the icid parameter from P-Charging- Vector header; and 

3) for INVITE dialogs, replace the saved Cseq header value received in the request such that the P-CSCF is able to 
release the session if needed; 

before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives any response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If these lists do not match, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 
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5.2.7.2 UE-originating case 

When the P-CSCF receives from the UE an INVITE request, the P-CSCF may require the periodic refreshment of the 
session to avoid hung states in the P-CSCF. If the P-CSCF requires the session to be refreshed, it shall apply the 
procedures described in RFC 4028 [58] clause 8. 

NOTE: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

The P-CSCF shall respond to all INVITE requests with a 100 (Trying) provisional response. 

If a PCRF exisls for ihe user for which a request is received, the P-CSCF shall also include the 
access-network-charging-info parameter (if received via the PCRF over the Rx or Gx interfaces) in the P-Charging- 
Vector header in the first request originated by the UE that traverses the P-CSCF, as soon as the charging information is 
available in the P-CSCF, e.g., after the local resource reservation is complete. Typically, this first request is an 
UPDATE request if the remote UA supports the "integration of resource management in SIP" extension or a re-INVITE 
request if the remote UA does not support the "integration of resource management in SIP" extension. See 
subclause 5.2.7.4 for further information on the access network charging information. 

5.2.7.3 UE-terminating case 

When the P-CSCF receives an INVITE request destined for the UE the P-CSCF may require the periodic refreshment of 
the session to avoid hung states in the P-CSCF. If the P-CSCF requires the session to be refreshed, it shall apply the 
procedures described in RFC 4028 [58] clause 8. 

NOTE 1: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 

cannot automatically be granted, i.e. at least one of the involved UEs needs to support it in order to make 
it work. 

When the P-CSCF receives an initial INVITE request destined for the UE, it will have a Ust of Record-Route headers. 
Prior to forwarding the initial INVITE, the P-CSCF shall respond to all INVITE requests with a 100 (Trying) 
provisional response. 

If a PCRF exists for the user for which a request or response is received, the P-CSCF shall also include the 
access-network-charging-info parameter (if received via the PCRF, over the Gr or Gx interfaces) in the P-Charging- 
Vector header in the first request or response originated by the UE that traverses the P-CSCF, as soon as the charging 
information is available in the P-CSCF e.g., after the local resource reservation is complete. Typically, this first 
response is a 180 (Ringing) or 200 (OK) response if the remote UA supports the "integration of resource management 
in SIP" extension, or a re-INVITE request if the remote UA does not support the "integration of resource management 
in SIP" extension. See subclause 5.2.7.4 for further information on the access network charging information. 

5.2.8.1 .1 Cancellation of a session currently being established 

Upon receipt of an indication that radio coverage is no longer available for a multimedia session currently being 
established (e.g. abort session request from PCRF), or of an indication that bearer resources are no longer available for a 
multimedia session currently being established (e.g. abort session request received from SPDF over the Gq' interface), 
the P-CSCF shall cancel that dialog by applying the following steps: 

1) if the P-CSCF serves the calling user of the session, send out a CANCEL request to cancel the INVITE request 
towards the terminating UE that includes a Reason header containing a 503 (Service Unavailable) status code 
according to the procedures described in RFC 3261 [26] and RFC 3326 [34A]; and 

2) if the P-CSCF serves the called user of the session, send out a 503 (Service Unavailable) response to the received 
INVITE request. 
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Upon receipt of an indication that QoS resources are no longer available for a multimedia session currently being 
established (e.g. abort session request from PCRF), or of an indication that bearer resources are no longer available for a 
multimedia session currently being established (e.g. abort session request received from SPDF over the Gq' interface), 
the P-CSCF shall cancel that dialog by responding to the original INVITE request with a 503 (Service Unavailable) 
response, and by sending out a CANCEL request to the INVITE request towards the terminating UE that includes a 
Reason header containing a 503 (Service Unavailable) status code according to the procedures described in 
RFC 3261 [26] and RFC 3326 [34A]. 

5.2.8.1 .2 Release of an existing session 

Upon receipt of an indication that the radio/bearer interface resources are no longer available for a session (e.g. abort 
session request PCRF), or of an indication that bearer resources are no longer available for a multimedia session 
currently being established (e.g. abort session request received from SPDF over the Gq' interface) or upon detecting that 
the SDP offer conveyed in a SIP response contained parameters which are not allowed according to the local policy (as 
specified in the subclause 6.2), the P-CSCF shall release the respective dialog by applying the following steps: 

1) if the P-CSCF serves the calling user of the session it shall generate a BYE request based on the information 
saved for the related dialog, including: 

- a Request-URI, set to the stored Contact header provided by the called user; 

- a To header, set to the To header value as received in the 200 (OK) response for the initial INVITE request; 

- a From header, set to the From header value as received in the initial INVITE request; 

- a Call-ID header, set to the Call-Id header value as received in the initial INVITE request; 

- a CSeq header, set to the current CSeq value stored for the direction from the calling to the called user, 
incremented by one; 

- a Route header, set to the routeing information towards the called user as stored for the dialog; 

- a Reason header that contains: 

- a 503 (Service Unavailable) response code, if radio/bearer interface resources are no longer available; or 

- a 488 (Not Acceptable Here) response code, if a SDP offer conveyed in a SIP response contained 
parameters which are not allowed according to the local policy; and 

- further headers, based on local policy. 

2) if the P-CSCF serves the calling user of the session and upon detecting that the SDP offer conveyed in a SIP 
response contained parameters which are not allowed according to the local policy (as specified in the 
subclause 6.2), then the P-CSCF shall generate an additional BYE request based on the information saved for the 
related dialog, including: 

a Request-URI. set to the stored Contact header provided by the calling user; 

a To header, set to the From header value as received in the initial INVITE request; 

- a From header, set to the To header value as received in the 200 (OK) response for the initial INVITE 
request; 

a Call-ID header, set to the Call-Id header value as received in the initial INVITE request; 

- a CSeq header, set to the current CSeq value stored for the direction from the called to the calling user, 

incremented by one; 

a Route header, set to the routeing information towards the calling user as stored for the dialog; 

- a Reason header that contains a 488 (Not Acceptable Here) response code; and 

- further headers, based on local policy. 

2) If the P-CSCF serves the called user of the session it shall generate a BYE request based on the information 
saved for the related dialog, including: 
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- a Request-URI, set to the stored Contact header provided by the calling user; 

- a To header, set to the From header value as received in the initial INVITE request; 

- a From header, set to the To header value as received in the 200 (OK) response for the initial INVITE 
request; 

- a CaU-ID header, set to the Call-Id header value as received in the initial INVITE request; 

- a CSeq header, set to the current CSeq value stored for the direction from the called to the calling user, 
incremented by one; 

- a Route header, set to the routeing information towards the calling user as stored for the dialog; 

- a Reason header that contains: 

- a 503 (Service Unavailable) response code;, if radio/bearer interface resources are no longer available; or 

- a 488 (Not Acceptable Here) response code, if SDP payload contained parameters which are not allowed 
according to the local poUcy; and 

- further headers, based on local policy. 

2A) if the P-CSCF serves the called user of the session and upon detecting that the SDP offer conveyed in a SIP 
response contained parameters which are not allowed according to the local policy (as specified in the 
subclause 6.2), then the P-CSCF shall generate an additional BYE request based on the information saved for the 
related dialog, including: 

- a Request-URI, set to the stored Contact header provided by the called user; 

- a To header, set to the To header value as received in the 200 (OK) response for the initial INVITE request; 
a From header, set to the From header value as received in the initial INVITE request; 

a Call-ID header, set to the Call-Id header value as received in the initial INVITE request; 

- a CSeq header, set to the current CSeq value stored for the direction from the calling to the called user, 
incremented by one; 

a Route header, set to the routeing information towards the called user as stored for the dialog; 

- a Reason header that contains a 488 (Not Acceptable Here) response code; and 

- further headers, based on local policy. 

3) send the so generated BYE requests towards the indicated users. 

4) upon receipt of the 2xx responses for the BYE requests, shall delete all information related to the dialog and the 
related multimedia session. 

5.2.8.1 .4 Release of the existing dialogs due to registration expiration and deletion of the 

security association 

If there are still active dialogs associated with the user after the security associations were deleted, the P-CSCF shall 
discard all information pertaining to these dialogs without performing any further SIP transactions with the peer entities 
of the P-CSCF. 

NOTE: At the same time, the P-CSCF will also indicate via the Rx or Gx or Gq' interface that the session has 
been terminated. 

5.2.8.3 Session expiration 

If the P-CSCF requested the session to be refreshed periodically, and the P-CSCF got the indication that the session will 
be refreshed, when the session timer expires, the P-CSCF shall delete aU the stored information related to the dialog. 
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NOTE: The P-CSCF will also indicate to the IP-CAN, via the Rx or Gx or Gq' interface, that the session has 
terminated. 

5.2.10.1 General 

If the P-CSCF belongs to a network where the registration is not required to obtain emergency service, the P-CSCF 
shall accept any unprotected request on the IP address and port advertised to the UE during the P-CSCF discovery 
procedure. The P-CSCF shall also accept any unprotected request on the same IP address and the default port as 
specified in RFC 3261 [26]. 

The P-CSCF can handle emergency session and other requests from both a registered user as well as an unregistered 
user. Certain networks only allow emergency session from registered users. 

NOTE 1 : If only emergency setup from registered users is allowed, a request from an unregistered user is ignored 
since it is received outside of the security association. 

The P-CSCF can handle emergency session estabhshment within a non-emergency registration. 

The P-CSCF shall not subscribe to the reg event package for any emergency public user identity. 

The P-CSCF shall store a configurable list of local emergency service identifiers, i.e. emergency numbers and the 
emergency service URN, which are vahd for the operator to which the P-CSCF belongs to. In addition to that, the 
P-CSCF shall store a configurable list of roaming partners' emergency service identifiers. 

NOTE 21: The emergency service URN are common to all networks, although subtypes may either not necessarily 
be in use, or a different set of subtypes is in use. The above requirements do not apply to subtypes of the 
emergency service URN. 

Access technology specific procedures are described in each access technology specific annex to determine whether the 
initial request for a dialog or standalone transaction or an unknown method is destined for a PSAP. 

NOTE 32:Depending on local operator pohcy, the P-CSCF has the capability to reject requests relating to specific 
methods in accordance with RFC 3261 [26], as an alternative to the fimctionality described above. 

When the P CSCF responds that the CS domain is to be used for emergency call the P CSCF shall include in the 380 
(Alternative Service) response a Content Type header field with the value set to associated MIME type of the 3GPP 
IMS XML body as described in subclause 7.6.1. 

The P CSCF shall include in the 3GPP IMS XML body: 

a) an <altemative service> element, set to the parameters of the alternative service: 

b) a <type> child element, set to "emergency" to indicate that it was an emergency call; and 

c) a <reason> child element, set to an operator configurable reason. 

The P CSCF can handle emergency session establishment within a non emergency registration. 

When the P CSCF responds that an emergency registration is required the P CSCF shall include in the 380 (Alternative 
Service) response a Content Type header field with the value set to associated MIME type of the 3GPP IMS XML body 
as described in subclause 7.6.1. The P CSCF shaU include in the 3GPP IMS XML body: 

a) an <altemative service> element, set to the parameters of the alternative service; 

b) a <type> child element, set to "emergency" to indicate that it was an emergency call; and 

c) an <action> child element, set to "emergency registration" to indicate that emergency registration is required; 

d) a <reason> child element, set to an operator configurable reason. 

NOTE A : <action> element is used only in a context to indicate the UE that emergency registration is required in 
the present document. Therefore, this element is defined as optional and shall not be used in other 
purpose. 
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NOTE 5: This response is only sent in case if the P CSCF received an explicit indication from the UE that it is an 

emergency session, i.e. receive emergency service URN in the Request URL 

For all SIP transactions identified as relating to an emergency, the P-CSCF shall give priority over other transactions. 
This allows special treatment (e.g. with respect to filtering, higher priority, routeing) of emergency sessions. The exact 
meaning of priority is not defined further in this document, but is left to national regulation and network configuration. 

5.2.1 0.3 General treatment for all dialogs and standalone transactions excluding the 

REGISTER method after emergency registration 

If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a 
registered user over the security association that was created during the emergency registration , the P-CSCF shall 
inspect the Request URI independent of values of possible entries in the received Route headers for known emergency 
service identifiers, i.e. emergency numbers and the emergency service URN from these configurable lists. 

If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone transaction, or an 
unknown method does not match any one of the emergency service identifiers in any of these Usts, the P-CSCF shall 
reject the request by returning a 403 (Forbidden) response to the UE. 

If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone transaction, or an 
unknown method matches one of the emergency service identifiers in any of these lists, the P-CSCF shall: 

1) include in the Request-URI an emergency service URN, i.e. with a service type of "sos" as specified in 
RFC 5031 [69], if necessary, and execute the procedure described in step 3, 4, 5, and 6, in subclause 5.2.6.3 
deahng with the procedure when the P-CSCF receives an initial request from the UE. The entry in the Request- 
URI that the P-CSCF includes may either be: 

as received from the UE in the Request URI in accordance with RFC 5031 [69]; or 

as deduced from the Request-URI received from the UE. 

2) if the request contains a Contact header field containing a GRUU the P-CSCF shall save the GRUU received in 
the Contact header field of the request and associate it with the UE IP address and UE protected server port, fe^ 
the security association on which the request was received such that the P-CSCF is able to route target refresh 
request containing that GRUU in the Request-URI; and 

In addition the P-CSCF shall execute the procedures as specified in subclause 5.2 with the following additions: 

3) the P-CSCF shall: 

if the registered emergency public user identity is included in the P-Preferred-Identity header, remove the P- 
Preferred-Identity header from the received request and insert a P-Asserted-Identity header that includes the 
emergency public user identity that was present in the P-Preferred-Identity header. Add a second P- Asserted 
identity header that contains the tel URI associated with the emergency public user identity. If the tel URI 
associated with the registered emergency public user identity is included in the 

P-Preferred-Identity header, check the validity of the tel URI, remove the P-Preferred-Identity header and 
insert a P-Asserted-Identity header that includes the tel URI that was present in the P-Preferred-Identity 
header. Add a second P-Asserted-Identity header that contains the emergency public user identity; and 

- select an E-CSCF and add the URI of the selected E-CSCF to the topmost Route header. 

NOTE: It is implementation dependant as to how the P-CSCF obtains the list of E-CSCFs. 

If the P-CSCF does not receive any response to the INVITE request (including its retransmissions); or receives a 3xx 
response or 480 (Temporarily Unavailable) response to an INVITE request, the P-CSCF shall select a new E-CSCF and 
forward the INVITE request. 

When the P-CSCF receives a target refresh request for a dialog with the Request-URI containing a GRUU the P-CSCF 
shall: 

- obtain the UE IP address and UE protected server port related to the GRUU contained in the Request-URI and 
rewrite the Request-URI with that UE IP address and UE protected server port; and 

- perform the steps in subclause 5.2.6.4 for when the P-CSCF receives, destined for the UE, a target refresh 
request for a dialog. 
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5.2.1 0.4 General treatment for all dialogs and standalone transactions excluding the 

REGISTER method - non-emergency registration 

If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a 
registered user the P-CSCF shall inspect the Request URI independent of values of possible entries in the received 
Route headers for known emergency service identifiers, i.e. emergency numbers and the emergency service URN from 
these configurable lists. If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone 
transaction, or an unknown method matches one of the emergency service identifiers in any of these lists, the P-CSCF 
shall: 

0) determine the geographical location of the UE. Access technology specific procedures are described in each 
access technologv specific annex. If the UE is roaming or the P-CSCF is in a different network than the UE's 
home operator's network, then the P-CSCF 

- shall reject the request by returning a 380 (Alternative Service) response to the UE. 

- shall assume that the UE supports version 1 of the XML Schema for the 3GPP IM CN subsystem XML body 
if support for the 3GPP IM CN subsystem XML body as described in subclause 7.6 in the Accept header is 
not indicated; and 

- shall include in the 380 (Alternative Service) response 

a Content-Type header field with the value set to associated MIME type of the 3GPP IM CN subsystem 
XML body as described in subclause 7.6.1; and 

- a P-Asserted-Identity header field set to the value of the SIP URI of the P-CSCF included in the Path 
header field during the registration of the user whose UE sent the request causing this response. 

The body shall contain: 

a) an <alternative-service> element, set to the parameters of the alternative service; 

b) a <type> child element, set to "emergency" to indicate that it was an emergency call; 

c) a <reason> child element, set to an operator configurable reason; and 

d) an <action> child element, set to "emergency-registration" if the request included an emergency service 
URN in the Request-URI. 

NOTE 1 : Roaming is when a UE is in a geographic area that is outside the serving geographic area of the home 
IMS system. 

NOTE 2: Emergency service URN in the request-URI indicates for the network that the emergency call attempt is 
recognized by the UE. 

1) include in the Request-URI an emergency service URN, i.e. a service URN with a top-level service type of "sos" 
as specified in draft-ietf-ecrit-service-urn [69], if necessary, and execute the procedure described in step 2, 3, 4, 
5, and 6, in subclause 5.2.6.3 dealing with the procedure when the P-CSCF receives an initial request from the 
UE. An additional sub-service type can be added if information on the type of emergency service is known. The 
entry in the Request-URI that the P-CSCF includes may either be: 

- as received from the UE in the Request URI in accordance with draft-ietf-ecrit-service-um [69]; or 

- as deduced from the Request-URI received from the UE; and 

2) if the request contains a Contact header field containing a GRUU the P-CSCF shall save the GRUU received in 
the Contact header field of the request and associate it with the UE IP address and UE protected server port, for 
the security association on which the request was received such that the P-CSCF is able to route target refresh 
request containing that GRUU in the Request-URI. 

In addition the P-CSCF shall execute the procedures as specified in subclause 5.2 with the following additions: 

3) the P-CSCF shall: 

if the public user identity included in the P-Preferred-Identity header matches one of the registered public 
user identities, remove the P-Preferred-Identity header from the received request and insert a P-Asserted- 
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Identity header that includes the public user identity that was present in the P-Preferred-Identity header. Add 
a second P- Asserted identity header that contains the tel URI associated with the public user identity. If the 
tel URI associated with one of the registered public user identities is included in the P-Preferred-Identity 
header, check the validity of the tel URI, remove the P-Preferred-Identity header and insert a P-Asserted- 
Identity header that includes the tel URI that was present in the P-Preferred-Identity header. Add a second P- 
Asserted-Identity header that contains a public user identity associated with the tel URI; 

- select an E-CSCF and add the URI of the selected E-CSCF to the topmost Route header. 

NOTE^: It is implementation dependant as to how the P-CSCF obtains the list of E-CSCFs. 

If the P-CSCF does not receive any response to the INVITE request (including its retransmissions); or receives a 3xx 
response or 480 (Temporarily Unavailable) response to an INVITE request, the P-CSCF shall select a new E-CSCF and 
forward the INVITE request. 

When the P-CSCF receives a target refresh request for a dialog with the Request-URI containing a GRUU the P-CSCF 
shall: 

- obtain the UE IP address and UE protected server port related to the GRUU contained in the Request-URI and 
rewrite the Request-URI with that UE IP address and UE protected server port; and 

- perform the steps in subclause 5.2.6.4 for when the P-CSCF receives, destined for the UE, a target refresh 
request for a dialog. 

5.2.10.5 Abnormal cases 

If the IM CN subsystem to where the P-CSCF belongs to is not capable to handle emergency sessions or due to local 
policy does not handle emergency sessions or only handles certain type of emergency session request or does not 
support emergency sessions for either the geographical location of the UE or the IP-CAN to which the UE is attached , 
the P-CSCF shall not forward the INVITE request. The P-CSCF 

- shall respond to the INVITE request with a 380 (Alternative Service) response , see subclause 5.2.10.1. 

shall assume that the UE supports version 1 of the XML Schema for the 3GPP IM CN subsystem XML bodv if 
support for the 3GPP IM CN subsystem XML body as described in subclause 7.6.1 in the Accept header is not 
indicated; and 

- shall include in the 380 (Alternative Service) response 

- a Content-Type header field with the value set to associated MIME type of the 3GPP IM CN subsystem 
XML bodv as described in subclause 7.6.1; and 

- a P-Asserted-Identity header field set to the value of the SIP URI of the P-CSCF included in the Path header 
field during the registration of the user whose UE sent the request causing this response. 

- The bodv shall contain: 

a) an <altemative-service> element, set to the parameters of the alternative service; 

b) a <tvpe> child element, set to "emergency" to indicate that it was an emergency call; 

c) a <reason> child element, set to an operator configurable reason; and 

d) an <action> child element, set to "emergency-registration" if the request included an emergency service URN 
in the Request-URI. 

NOTE 1: Emergency service URN in the request-URl indicates for tlic network that the emergency call attempt is 
recognized by the UE. 

NOTE^: Some networks only allow session requests with a Request-URI containing an emergency service URN, 
i.e. a service URN with a top-level service type of "sos" as specified in draft-ietf-ecrit-service-urn [69]. 

5.3.2.1 Normal procedures 

The I-CSCF may behave as a stateful proxy for initial requests. 



ETSI 



Release 7 



67 



ETSI TS 124 503 V8.6.0 (2009-09) 



Upon receipt of a request, the I-CSCF shall perform the originating procedures as described in subclause 5.3.2.1 A if the 
topmost Route header of the request contains the "orig" parameter. Otherwise, the I-CSCF shall continue with the rest 
of the procedures of this subclause. 

When the I-CSCF receives a request, the I-CSCF shall verify whether it has arrived from a trusted domain or not. If the 
request has arrived from a non trusted domain, then the I-CSCF shall remove all P Asserted Identity headers, all P 
Access Network Info headers, all P-Charging- Vector headers and all P-Charging-Function- Addresses headers the 
request may contain. 

NOTE 1 : The I-CSCF can find out whether the request arrived from a trusted domain or not, from the procedures 
described in 3GPP TS 33.210 [19A]. 

The I-CSCF shall discard the P-Profile Key header, if the I-CSCF receives the Profile Key header in a SIP request or 
response. 

When the I-CSCF receives, destined for a server user or a PSI, an initial request for a dialog or standalone transaction 
the 1-CSCF shall: 

1) if the Request-URI includes: 

a) a pres: or an im: URI, then translate the pres: or im: URI to a public user identity and replace the Request- 
URI of the incoming request with that public user identity; or 

b) a SIP-URI that is not a GRUU and with the user part starting with a + and the user parameter equals "phone" 
then replace the Request-URI with a tel-URI with the user part of the SIP-URI in the telephone-subscriber 
element in the tel-URI; or 

c) a SIP URI that is a GRUU, then obtain the public user identity from the Request-URI and use it for location 
query procedure to the HSS. When forwarding the request, the I-CSCF shall not modify the Request-URI of 
the incoming request; 

NOTE 2: If the Request-URI is a GRUU with the user part starting with a + and the user parameter equals "phone", 
the 1-CSCF builds a tel URI from the user part and uses it only to query the HSS. Subsequently, when the 
I-CSCF forwards the request to the S-CSCF, it will not modify the Request-URI. 

NOTE 3: SRV records have to be advertised in DNS pointing to the I-CSCF for pres: and im: queries. 

2) remove a Route header, if present; and 

3) check if the domain name of the Request-URI matches with one of the PSI subdomains configured in the I- 
CSCF. If the match is successful, the I-CSCF resolves the Request-URI by an internal DNS mechanism into the 
IP address of the AS hosting the PSI and does not start the user location query procedure. Otherwise, the I-CSCF 
will start the user location query procedure to the HSS as specified in 3GPP TS 29.228 [14] for the called PSI or 
user, indicated in or derived from the Request-URI. Prior to performing the user location query procedure to the 
HSS, the I-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator 
Functional (SLF) entity as specified in 3GPP TS 29.228 [14]. 

When the I-CSCF receives any response to such a request, the I-CSCF shall store the value of the term-ioi parameter 
received in the P-Charging- Vector header, if present. 

NOTE 4: Any received term-ioi parameter will be a type 3 term-ioi. The type 3 term-ioi identifies the service 

provider from which the response was sent. 

When the I-CSCF receives an INVITE request, the I-CSCF may require the periodic refreshment of the session to avoid 
hung states in the I-CSCF. If the I-CSCF requires the session to be refreshed, it shall apply the procedures described in 
RFC 4028 [58] clause 8. 

NOTE 5: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

In case the I-CSCF is able to resolve the Request-URI into the IP address of the AS hosting the PSI, then it shall: 

1) store the value of the icid parameter received in the P-Charging-Vector header and retain the icid parameter in 
the P-Charging- Vector header. If no icid parameter was found, then create a new, globally unique value for the 
icid parameter and insert it into the P-Charging-Vector header; and 
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2) forward the request directly to the AS hosting the PSI. 
Upon successful user location query, when the response contains the URI of the assigned S-CSCF, the I-CSCF shall: 

1) insert the URI received from the HSS as the topmost Route header; 

2) store the value of the icid parameter received in the P-Charging- Vector header and retain the icid parameter in 
the P-Charging-Vector header. If no icid parameter was found, then create a new, globally unique vidue for the 
icid parameter and insert it into the P-Charging- Vector header. The I-CSCF shall add a type 3 orig-ioi parameter 
before the received orig-ioi parameter. The I-CSCF shall set the type 3 orig-ioi parameter to a value that 
identifies the sending network of the request. The I-CSCF shall not include the type 3 term-ioi parameter; 

3) optionally, include the received Redirect-Host AVP value in the P-User-Database header as defined in 
RFC 4457 [82]; and 

4) forward the request based on the topmost Route header. 

NOTE 6: The P-User-Database header can be included only if the I-CSCF can assume (e.g. based on local 
configuration) that the receiving S-CSCF will be able to process the header. 

Upon successful user location query, when the response contains information about the required S-CSCF capabilities, 
the I-CSCF shall: 

1) select a S-CSCF according to the method described in 3GPP TS 29.228 [14]; 

2) insert the URI of the selected S-CSCF as the topmost Route header field value; 

3) execute the procedure described in step 2 and 3 in the above paragraph (upon successful user location query, 
when the response contains the URI of the assigned S-CSCF); 

4) optionally, include the received Redirect-Host AVP value in the P-User-Database header as defined in 
RFC 4457 [82]; 

5) if the Wildcarded PSI value is received from the HSS in the Wildcarded-PSI AVP or a wildcarded pubUc user 
identity value is received from the HSS in the Wildcarded-IMPU AVP and the 1-CSCF supports the the SIP P- 
Profile-Key private header extension, include the wildcarded PSI value in the P-Profile-Key header as defined in 
draft-camarillo-sipping-profile-key [97]; and 

6) forward the request to the selected S-CSCF. 

NOTE 7: The P-User-Database header can be included only if the I-CSCF can assume (e.g. based on local 
configuration) that the receiving S-CSCF will be able to process the header. 

Upon an unsuccessful user location query when the response from the HSS indicates that the user does not exist, and if 
the Request-URI is a tel URI containing a public telecommunications number as specified in RFC 3966 [22], the I- 
CSCF may support a local configuration option that indicates whether or not request routeing is to be attempted. If the 
local configuration option indicates that request routeing is to be attempted, then the I-CSCF shall perform one of the 
following procedures based on local operator policy: 

1) forward the request to the transit functionality for subsequent routeing; or 

2) invoke the portion of the transit functionality that translates the public telecommunications number contained in 
the Request-URI to a routeable SIP URI, and process the request based on the result, as follows: 

a) if the translation fails, the request may be forwarded to a BGCF or any other appropriate entity (e.g. a MRFC 
to play an announcement) in the home network, or the 1-CSCF may send an appropriate SIP response to the 
originator, such as 404 (Not Found) or 604 (Does not exist anywhere). When forwarding the request to a 
BGCF or any other appropriate entity, the I-CSCF shall leave the original Request-URI containing the tel 
URI unmodified; or 

b) if this translation succeeds, then replace the Request-URI with the routeable SIP URI and process the request 
as follows: 

- determine the destination address (e.g. DNS access) using the URI placed in the topmost Route header if 
present, otherwise based on the Request-URI. If the destination requires interconnect functionalities (e.g. 
the destination address is of an IP address type other than the IP address type used in the IM CN 
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subsystem), the I-CSCF shall forward the request to the destination address via an IBCF in the same 
network; 

- if network hiding is needed due to local policy, put the address of the IBCF to the topmost route header; 
and 

- route the request based on SIP routeing procedures. 

Upon an unsuccessful user location query when the response from the HSS indicates that the user does not exist, and if 
local operator policy does not indicate that request routeing is to be attempted, then, the I-CSCF shall return an 
appropriate unsuccessful SIP response. This response may be a 404 (Not found) or 604 (Does not exist anywhere) in the 
case the user is not a user of the home network. 

Upon an unsuccessful user location query when the response from the HSS indicates that the user is not registered and 
no services are provided for such a user, the I-CSCF shall return an appropriate unsuccessful SIP response. This 
response may be a 480 (Temporarily unavailable) response if the user is recognized as a vahd user, but is not registered 
at the moment and it does not have services for unregistered users. 

When the I-CSCF receives an initial request for a dialog or standalone transaction, that contains a single Route header 
pointing to itself, the I-CSCF shall determine from the entry in the Route header whether it needs to do HSS query. In 
case HSS query is needed, then the I-CSCF shall: 

1) remove its own SIP URI from the topmost Route header; and 

2) route the request based on the Request-URI header field. 

When the I-CSCF receives an initial request for a dialog or standalone transaction containing more than one Route 
header, the I-CSCF shall: 

1) remove its own SIP URI from the topmost Route header;and 

2) forward the request based on the topmost Route header. 

NOTE 8: In accordance with SIP the I-CSCF can add its own routeable SIP URI to the top of the Record-Route 
header to any request, independently of whether it is an initial request. The P-CSCF will ignore any 
Record-Route header that is not in the initial request of a dialog. 

When the I-CSCF receives a response to an initial request (e.g. 183 (Session Progress) response or 2xx response), the I- 
CSCF shall store the values from the P-Charging-Function- Addresses header, if present. If the next hop is outside of the 
current network, then the I-CSCF shall remove the P-Charging-Function- Addresses header prior to forwarding the 
message. 

When the I-CSCF, upon sending an initial INVITE request to the S-CSCF, receives a 305 (Use Proxy) response from 
the S-CSCF, it shall forward the initial INVITE request to the SIP URI indicated in the Contact field of the 305 (Use 
Proxy) response, as specified in RFC 3261 [26]. 

5.3.2.1 A Originating procedures for requests containing tlie "orig" parameter 

The procedures of this subclause apply for requests received at the I-CSCF when the topmost Route header of the 
request contains the "orig" parameter. 

The I-CSCF shall verify for all requests whether they arrived from a trusted domain or not. If the request arrived from a 
non trusted domain, then the I-CSCF shall respond with 403 (Forbidden) response. 

If the request arrived from a trusted domain, the 1-CSCF shall perform the procedures below. 

NOTE 1 ; The I-CSCF can find out whether the request arrived from a trusted domain or not, from the procedures 
described in 3GPP TS 33.210 [19A]. 

When the I-CSCF receives an initial request for a dialog or standalone transaction the I-CSCF will start the user 
location query procedure to the HSS as specified in 3GPP TS 29.228 [14] for the calling user, indicated in the P- 
Asserted-Identity header. Prior to performing the user location query procedure to the HSS, the I-CSCF decides which 
HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 
3GPPTS 29.228 [14]. 
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When the I-CSCF receives an INVITE request, the I-CSCF may require the periodic refreshment of the session to avoid 
hung states in the I-CSCF. If the I-CSCF requires the session to be refreshed, it shall apply the procedures described in 
RFC 4028 [58] clause 8. 

NOTE 2: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

When the response for user location query contains information about the required S-CSCF capabilities, the I-CSCF 
shall select a S-CSCF according to the method described in 3GPP TS 29.228 [14]. 

If the user location query was successful, the I-CSCF shall: 

1) insert the URI of the S-CSCF - either received from the HSS, or selected by the I-CSCF based on capabiUties - 
as the topmost Route header appending the "orig" parameter to the URI of the S-CSCF; 

2) store the value of the icid parameter received in the P-Charging- Vector header and retain the icid parameter in 
the P-Charging-Vector header. If no icid parameter was found, then create a new, globally unique value for the 
icid parameter and insert it into the P-Charging- Vector header; 

3) optionally, include the received Redirect-Host AVP value in the P-User-Database header as defined in draft- 
camariUo-sipping-user-database [82] 

3a) if a wildcarded public user identity value is received from the HSS in the Wildcarded-IMPU AVP and the I- 
CSCF supports the the SIP P-Profile-Kev private header extension, include the wildcarded public user identity 
value in the P-Profile-Key header as defined in RFC 5002 [97]; and 



4) forward the request based on the topmost Route header. 

NOTE 3: The P-User-Database header can be included only if the I-CSCF can assume (e.g. based on local 
configuration) that the receiving S-CSCF will be able to process the header. 

Upon an unsuccessful user location query, the I-CSCF shall return an appropriate unsuccessful SIP response. This 
response may be a 404 (Not found) response or 604 (Does not exist anywhere) response in the case the user is not a user 
of the home network. 

When the I-CSCF receives any response to the above request, and forwards it to AS, the I-CSCF shall: 

store the values from the P-Charging-Function- Addresses header, if present. If the next hop is outside of the 
current network, then the I-CSCF shall remove the P-Charging-Function-Addresses header prior to forwarding 
the message; and 

- insert a P-Charging-Vector header containing the type 3 orig-ioi parameter, if received in the request, and a type 
3 term-ioi parameter in the response. The I-CSCF shall set the type 3 term-ioi parameter to a value that identifies 
the sending network of the response and the type 3 orig-ioi parameter is set to the previously received value of 
type 3 orig-ioi. 



5.4.1.1 Introduction 

The S-CCF shall act as the SIP registrar for all UAs belonging to the IM CN subsystem and with public user identities. 

Subclause 5.4.1.2 through subclause 5.4.1.7 define S-CCF procedures for SIP registration that do not relate to 
emergency. All registration requests are first screened according to the procedures of subclause 5.4.8.2 to see if they do 
relate to an emergency public user identity. 

The S-CCF shall support the use of the Path and Service-Route header. The S-CCF shall also support the Require and 
Supported headers. The Path header is only applicable to the REGISTER request and its 200 (OK) response. The 
Service-Route header is only applicable to the 200 (OK) response of REGISTER. The S-CCF shall not act as a redirect 
server for REGISTER requests. 

The network operator defines minimum and maximum times for each registration. These values are provided within the 
S-CCF. 
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The procedures for notification concerning automatically registered public user identities of a user are described in 
subclause 5.4.2.1.2. 

In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT, the 
S-CCF may need to modify the SIP signalling according to the procedures described in annex K if both a reg-id and 
instance ID parameter are present in the received contact header as described in draft-ieft-outbound [92]. 

The S-CCF shall determine based on the contents of the REGISTER request whether procedure for IMS-AKA 
authentication are to be performed or not: 

if the REGISTER request contains an Authorization header field with the 'integrity-protected' parameter, the 
S-CCF shall perform the initial registration procedures with IMS-AKA authentication described in subclause 
5.4.1.2.1: 

- otherwise (i.e. no Authorization header field is present, or Authorization header field is received without the 
"integrity-protected" parameter), the S-CCF shall perform the initial registration procedures as described in 
subclause 5.4. 1 .2A. 

5.4.1 .2 Initial registration and user-initiated reregistration with IMS-AKA authentication 

5.4.1.2.1 Unprotected REGISTER 

NOTE 1: Any REGISTER request sent unprotected with the "integrity-protected" parameter in the Authorization 
header set to "no" b y the UE is considered to be an initial registration. A 200 (OK) final response to such 
a request will only be sent back after the S-CCF receives a correct authentication challenge response in a 
REGISTER request that is sent integrity protected. 

NOTE 2: A REGISTER with Expires header value equal to zero should always be received protected. However, it 
is possible that in error conditions a REGISTER with Expires header value equal to zero may be received 
vmprotected. In that instance the procedures below will be appUed. 

Upon receipt of a REGISTER request without an "integrity protected" parameter, or with the "integrity-protected" 
parameter in the Authorization header set to "no", for a user identity linked to a private user identity that has a registered 
public user identity but with a new contact address, the S-CCF shall: 

1) perform the procedure for receipt of a REGISTER request without an "integrity protected" parameter, or with 
the "integrity-protected" parameter in the Authorization header set to "no"', for the received public user identity; 
and 

2) if the authentication has been successful, and there are public user identities belonging to this user that have been 
previously registered with an old contact address different from the one received in the REGISTER request and 
the previous registrations have not expired, the S-CCF shall perform the network initiated deregistration 
procedure for the previously registered public user identities and the associated old contact address as described 
in subclause 5.4.1.5. 

NOTE 3: Contact related to emergency registration is not affected. S-CCF is not able deregister contact related to 
emergency registration and will not delete that. 

When S-CCF receives a REGISTER request with the "integrity-protected" parameter in the Authorization header set to 
"no" and a non-empty response directive, the S-CCF shall ignore the value of the response directive. 

Upon receipt of a REGISTER request without an "integrity protected" parameter, or with the "integrity-protected" 
parameter in the Authorization header set to "no", which is not for an already registered pubhc user identity linked to 

the same private user identity, the S-CCF shall: 

1) identify the user by the public user identity as received in the To header and the private user identity as received 
in the username field in the Authorization header of the REGISTER request; 

2) check if the P-Visited-Network header is included in the REGISTER request, and if it is included identify the 
visited network by the value of this header; 

3) select an authentication vector for the user. If no authentication vector for this user is available, after the S-CCF 
has performed the Cx Multimedia Authentication procedure with the HSS, as described in 3GPP TS 29.228 [14], 
the S-CCF shall select an authentication vector as described in 3GPP TS 33.203 [19]. 
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Prior to performing Cx Multimedia Authentication procedure with the HSS, the S-CCF decides which HSS to 
query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 
3GPP TS 29.228 [14] or use the value as received in the P-User-Database header in the REGISTER request as 
defined in RFC 4457 [82]; 

NOTE 4: The HSS address received in the response to SLF query or as a value of P-User-Database header can be 
used to address the HSS of the public user identity in further queries. 

NOTE 5: At this point the S-CCF informs the HSS that the user currently registering will be served by the S-CCF 
by passing its SIP URI to the HSS. This will be used by the HSS to direct all subsequent incoming initial 
requests for a dialog or standalone transactions destined for this user to this S-CCF. 

NOTE 6: When passing its SIP URI to the HSS, the S-CCF may include in its SIP URI the transport protocol and 
the port number where it wants to be contacted. 

4) store the icid parameter received in the P-Charging- Vector header; 

5) challenge the user by generating a 401 (Unauthorized) response for the received REGISTER request, including a 
WWW-Authenticate header which transports: 

- a globally unique name of the S-CCF in the realm field; 

- the RAND and AUTN parameters and optional server specific data for the UE in the nonce field; 
the security mechanism, which is AKAvl-MD5, in the algorithm field; 

- the IK (Integrity Key) parameter for the P-CSCF in the ik field (see subclause 7.2A. 1); and 

- the CK (Cipher Key) parameter for the P-CSCF in the ck field (see subclause 7.2A. 1 ); 

6) store the RAND parameter used in the 401 (Unauthorized) response for future use in case of a resynchronization. 
If a stored RAND aheady exists in the S-CCF, the S-CCF shall overwrite the stored RAND with the RAND used 
in the most recent 401 (Unauthorized) response; 

7) send the so generated 401 (Unauthorized) response towards the UE; and, 

8) start timer reg-await-auth which guards the receipt of the next REGISTER request. 

If the received REGISTER request indicates that the challenge sent previously by the S-CCF to the UE was deemed to 
be invalid by the UE, the S-CCF shall stop the timer reg-await-auth and proceed as described in the subclause 5.4.1.2.3. 

5.4.1.2.2 Protected REGISTER 

Upon receipt of a REGISTER request with the "integrity-protected" parameter in the Authorization header set to "yes", 
the S-CSCF shall identify the user by the public user identity as received in the To header and the private user identity 
as received in the Authorization header of the REGISTER request, and: 

In the case that there is no authentication currently ongoing for this user (i.e. no timer reg-await-auth is running): 

1) check if the user needs to be reauthenticated. 

The S-CSCF may require authentication of the user for any REGISTER request, and shall always require 
authentication for REGISTER requests received without the "integrity-protected" parameter in the Authorization 

header set to "yes". 

If the user needs to be reauthenticated, the S-CSCF shall proceed with the procedures as described for the 
un protected initial REGISTER in subclause 5.4.1.2.1, beginning with step 34). If the user does not need to be 
reauthenticated, the S-CSCF shall proceed with the following steps in this paragraph; and 

2) check whether an Expires timer is included in the REGISTER request and its value. If the Expires header 
indicates a zero value, the S-CSCF shall perform the deregistration procedures as described in subclause 5.4.1.4. 
If the Expires header does not indicate zero, the S-CSCF shall check whether the public user identity received in 
the To header is already registered. If it is not registered, the S-CSCF shall proceed beginning with step 5 below. 
Otherwise, the S-CSCF shall proceed beginning with step 6 below. 
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In the case that a timer reg-await-auth is ranning for this user the S-CSCF shall: 

1) check if the Call-ID of the request matches with the Call-ID of the 401 (Unauthorized) response which carried 
the last challenge. The S-CSCF shall only proceed further if the Call-IDs match. 

2) stop timer reg-await-auth; 

3) check whether an Authorization header is included, containing: 

a) the private user identity of the user in the username field; 

b) the algorithm which is AKAvl-MD5 in the algorithm field; and 

c) the authentication challenge response needed for the authentication procedure in the response field. 

The S-CSCF shall only proceed with the following steps in this paragraph if the authentication challenge 
response was included; 

4) check whether the received authentication challenge response and the expected authentication challenge 
response (calculated by the S-CSCF using XRES and other parameters as described in RFC 3310 [49]) match. 
The XRES parameter was received from the HSS as part of the Authentication Vector. The S-CSCF shall only 
proceed with the following steps if the challenge response received from the UE and the expected response 
calculated by the S-CSCF match; 

5) after performing the Cx Server Assignment procedure with the HSS, as described in 3GPP TS 29.228 [14], store 
the following information in the local data: 

a) the hst of pubhc user identities, including the registered own public user identity and its associated set of 
implicitly registered pubhc user identities and wildcarded pubhc user identities due to the received 
REGISTER request. Each pubhc user identity is identified as either barred or non-barred; and, 

b) all the service profile(s) corresponding to the public user identities being registered (exphcitly or implicitly), 
including initial Filter Criteria(the initial Filter Criteria for the Registered and common parts is stored and the 
unregisterd part is retained for possible use later - in the case of the S-CSCF is retained if the user becomes 
unregistered); 

NOTE 1: There might be more than one set of initial Filter Criteria received because some implicitly registered 

public user identities that are part of the same implicit registration set belong to different service profiles. 

6) update registration bindings: 

a) bind to each non-barred registered public user identity all registered contact information including all header 
parameters contained in the Contact header and aU associated URI parameters, with the exception of the URI 
"pub-gruu" and "temp-gruu" parameters as specified in draft-ietf-sip-gruu [93], and store information for 
future use; 

b) for each binding that contains a -nsip.instance header parameter, assign a new temporary GRUU, as specified 
in subclause 5.4.7A.3. 

NOTE 2: There might be more then one contact information available for one public user identity. 
NOTE 3: The barred pubhc user identities are not boimd to the contact information. 

7) check whether a Path header was included in the REGISTER request and construct a hst of preloaded Route 
headers from the list of entries in the received Path header. The S-CSCF shall preserve the order of the preloaded 
Route headers and bind them to the contact information that was received in the REGISTER message; 

NOTE 4: If this registration is a reregistration or an initial registration (i.e., there are previously registered public 
user identities belonging to the user that have not been deregistered or expired), then a list of pre-loaded 
Route headers will already exist. The new list replaces the old hst. 

8) determine the duration of the registration by checking the value of the Expires header in the received REGISTER 
request. The S-CSCF may reduce the duration of the registration due to local policy or send back a 423 (Interval 
Too Brief) response specifying the minimum allowed time for registration; 

9) store the icid parameter received in the P-Charging- Vector header; 
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10) if an orig-ioi parameter is received in the P-Charging- Vector header, store the value of the received orig-ioi 

parameter; 

NOTE 5: Any received orig-ioi parameter will be a type 1 orig-ioi. The type 1 orig-ioi identifies the network from 
which the request was sent. 

11) create a 200 (OK) response for the REGISTER request, including: 

a) the list of received Path headers; 

b) a P-Associated-URl header containing the list of the registered public user identity and its associated set of 
implicitly registered public user identities. The first URI in the list of public user identities supplied by the 
HSS to the S-CSCF will indicate the default public user identity to be used by the S-CSCF. The public user 
identity indicated as the default pubhc user identity must be a registered public user identity. The S-CSCF 
shall place the default pubhc user identity as the first entry in the hst of URIs present in the P-Associated- 
URl header. The default public user identity will be used by the P-CSCF in conjunction with the procedures 
for the P-Asserted-ldentity header, as described in subclause 5.2.6.3. If the S-CSCF received a display name 
from the HSS for a pubhc user identity, then it shall populate the P-Associated-URI header entry for that 
public identity with the associated display name. The S-CSCF shall not add a barred pubhc user identity to 
the list of URIs in the P-Associated-URl header; 

NOTE 6: The P-Associated-URI header lists only the pubhc user identity and its associated set of implicitly 

registered public user identities that have been registered, rather than the list of user's URIs that may be 
either registered or unregistered as specified in the RFC 3455 [52]. If the registered public user identity 
which is not barred does not have any other associated public user identities, the P-Associated-URJ 
header lists only the registered public user identity itself, rather than an empty P-Associated-URI header 
as specified in RFC 3455 [52]. 

c) a Service-Route header containing: 

the SIP URI identifying the S-CSCF containing an indication that requests routed via the service route 
(i.e. from the P-CSCF to the S-CSCF) are treated as for the UE-originating case. This indication may e.g. 
be in a URI parameter, a character string in the user part of the URI or be a port number in the URI; and, 

if network topology hiding is required a SIP URI identifying an IBCF as the topmost entry; 

d) a P-Charging-Function-Addresses header containing the values received from the HSS if the P-CSCF is in 
the same network as the S-CSCF. It can be determined if the P-CSCF is in the same network as the S-CSCF 
by the contents of the P-Visited-Network-ID header field included in the REGISTER request; 

e) a P-Charging-Vector header containing the orig-ioi parameter, if received in the REGISTER request and a 
type 1 term-ioi parameter. The S-CSCF shall set the type 1 term-ioi parameter to a value that identifies the 
sending network of the response and the orig-ioi parameter is set to the previously received value of orig-ioi; 

f) a Contact header listing all contact addresses for this public user identity, including all saved header and URI 
parameters (including all ICSI values and lARI values) received in the Contact header field of the 
REGISTER request, and 

g) gruus in the Contact header. If the REGISTER request contained a Required or Supported header containing 
the value "gruu" then for each contact address in the contact header that has a +sip.instance header parameter, 
add "pub-gruu" and "temp-gruu" header parameters. The values of these parameters shall contain, 
respectively, the public GRUU and the most recently assigned temporary GRUU representing (as specified in 
subclause 5.4.7A) the association between the public user identity from the To header in the REGISTER 
request and the instance ID contained in the +sip.instance parameter. 

NOTE 7: There might be other contact addresses available, that other UEs have registered for the same public user 
identity. 

12) send the so created 200 (OK) response to the UE; 

13) for all service profiles in the implicit registration set send a third-party REGISTER request, as described in 
subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS for the 
REGISTER event; and, 

NOTE 8: If this registration is a reregistration, the Filter Criteria already exists in the local data. 



ETSI 



Release 7 



75 



ETSI TS 124 503 V8.6.0 (2009-09) 



NOTE 9: If the same AS matches the Filter Criteria of several service profiles for the event of REGISTER request, 
then the AS will receive several third-party REGISTER requests. Each of these requests will include a 
public user identity from the corresponding service profile. 

14) consider the public user identity being registered to be boimd to the contact address specified in the Contact 
header for the duration indicated in the Expires header. 

5.4.1 ■2A Initial registration and user-initiated reregistration for non IMS-AKA authentication 

Upon receipt of a REGISTER request without the "integrity-protected" parameter in the Authorization header or 
without an Authorization header, for a user identity linked to a private user identity that has a registered public user 
identity but with a new contact address, the S-CCF shall: 

1) perform the procedure for receipt of a REGISTER request without the "integrity-protected" parameter in the 
Authorization header or without the Authorization header, for the received public user identity; and 

2) if the authentication has been successful, and there are public user identities belonging to this user that have been 
previously registered with an old contact address different from the one received in the REGISTER request and 
if the previous registration have not expired, the S-CCF shall perform the network initiated deregistration 
procedure for the previously registered public user identities and the associated old contact address as described 
in subclause 5.4.1.5. 

NOTE 1: Contact related to emergency registration is not affected. S-CCF is not able deregister contact related to 
emergency registration and will not delete that. 

Upon receipt of a REGISTER request without the "integrity-protected" parameter in the Authorization header or 
without an Authorization header, which is not for an already registered public user identity linked to the same private 
user identity, the S-CCF shall: 

1) identify the user by the pubhc user identity as received in the To header of the REGISTER request and if the 
Authorization header is present, the private user identity as received in the Authorization header of the 
REGISTER request; 

2) check if the P-Visited-Network header is included in the REGISTER request, and if it is included identify the 
visited network by the value of this header; 

3) check whether one or more Line-Identifiers previously received over the Cx interface, and stored as a result of a 
Cx Multimedia Authentication procedure with the HSS, are available for the user. If not, the S-CCF shall 
perform the Cx Multimedia Authentication procedure with the HSS, as described in [141. 

Prior to performing Cx Multimedia Authentication procedure with the HSS, the S-CCF decides which HSS to 
query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 
3GPP TS 29.228 [141 or use the value as received in the P-User-Database header in the REGISTER request as 
defined in RFC 4457 [821; 

NOTE 2: The HSS address received in the response to SLF query or as a value of P-User-Database header can be 
used to address the HSS of the public user identity in further queries. 

NOTE 3: At this point the S-CCF informs the HSS that the user currently registering will be served by the S-CCF 
by passing its SIP URI to the HSS. This will be used by the HSS to direct all subsequent incoming initial 
requests for a dialog or standalone transactions destined for this user to this S-CCF. 

NOTE 4: When passing its SIP URI to the HSS, the S-CCF may include in its SIP URI the transport protocol and 
the port number where it wants to be contacted. 

4) store the icid parameter received in the P-Charging- Vector header; 

5) In the particular case where the S-CCF received via the Cx interface one or more Line-Identifiers, compare each 
of the 'dsl-location' parameter of the P-Access-Network-Info header field (if present and if it includes the 
'network-provided' parameter), 

-if one of these match, the user shall be considered authenticated and the S-CCF behave as described in step 5) to 
13) of subclause 5.4.1.2.2; 
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-otherwise i.e. if these do not match the S-CCF shall return a 403 (Forbidden) response to the REGISTER 

request; and 

6) if no Line-Identifier is received over the Cx interface, send a 500 (Server Internal Error) response to the 
REGISTER request. 

Upon receipt of a REGISTER request without the "integrity-protected" parameter in the Authorization header or 
without an Authorization header, for an already registered public user identity linked to the same private user identity, 
and for existing contact information, the S-CCF shall behave as described in step 6) to 13) of subclause 5.4.1.2.2. 

5.4.1 ■2A.1 Abnormal cases 

In the case that the expiration timer from the UE is too short to be accepted by the S-CCF, the S-CCF shall: 

- reject the REGISTER request with a 423 (Interval Too Brief) response, containing a Min-Expires header with 
the minimum registration time the S-CCF will accept. 

On receiving a failure response to one of the third-party REGISTER requests, based on the information in the Filter 
Criteria the S-CCF may: 

- abort sending third-party REGISTER requests; and 

- initiate network-initiated deregistration procedure. 

If the Filter Criteria does not contain instruction to the S-CCF regarding the failure of the contact to the AS, the S-CCF 
shall not initiate network-initiated deregistration procedure. 

In the case that the REGISTER request from the UE contains more than one SIP URIs as Contact header entries, the 
S-CCF shall store: 

- the entry in the Contact header with the highest "q" ; or 

- an entry decided by the S-CCF based on local policy; 
and include it in the 200 (OK) response. 

5.4.1 .3 Authentication and reautlnentication 

Authentication and reauthentication is performed by the registration procedures as described in subclause 5.4.1.2 or 
5.4.1.2A . 

5.4.1 .4 User-initiated deregistration 

When S-CCF receives a REGISTER request with the Expires header field containing the value zero, the S-CCF shall: 

- check whether any of the following conditions apply. The S-CCF shall only proceed with the following steps if 
either one of the conditions is met; 

a) (case for using IMS-AKA authentication) the "integrity-protected" parameter in the Authorization header 
field set to "yes", indicating that the REGISTER request was received integrity protected; or 

b) (case for non IMS-AKA authentication) 

the "integrity-protected" parameter in the Authorization header field does not exist or yyithout an 

Authorization header, and one or more Line-Identifiers previously received over the Cx interface, stored as 
a result of a Cx Multimedia Authentication procedure with the HSS, are available for the user; 

The S CCF shall only proceed with the following steps if the "integrity protected" parameter is set to "yes"; 

release all dialogs that includes this user 's registered contact address , where the dialogs were initiated by or 
terminated towards this contact UE with the registered contact address for which the same public user identity 
found in the To header field that was received in the REGISTER request or with one of the implicitiy registered 
public user identities by applying the steps listed in subclause 5.4.5.1.2. However: 

- if the dialog that was established by the UE subscribing to the reg event package used the public user identity 
that is going to be deregistered; and 
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- this dialog is the only remaining dialog used for subscription to reg event package; 

then the S-CCF shall not release this dialog; 

if this public user identity was registered only by this UE, deregister the public user identity found in the To 
header field together with the implicitly registered public user identities. Otherwise, the S-CCF will only remove 
the contact address that was registered by this UE; 

NOTE: If the UE sends a REGISTER request with the value "*" in the Contact header and the value zero in the 
Expires header, the S-CCF will only remove the contact address that was registered by this UE identified 
with its private user identity. 

for all service profiles in the implicit registration set send a third-party REGISTER request, as described in 
subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS for the 
REGISTER event; and 

- if this is a deregistration request for the only pubUc user identity currently registered with its associated set of 
implicitly registered public user identities (i.e. no other is registered) and there are still active multimedia 
sessions that includes this user 's registered contact address , where the session was initiated bv or terminated 
towards the contact with the registered contact address for that public user identity which is currently registered 
or with one of the implicitly registered public user identities, release only each of these multimedia sessions 
associated with the registered contact address by applying the steps listed in subclause 5.4.5.1.2. Only dialogs 
associated to the multimedia sessions originated or terminated towards the registered user 's contact address shall 
be released. 

If all public user identities of the UE are deregistered, then the S-CCF may consider the UE and P-CSCF subscriptions 
to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header containing 
a value of zero). 

If the Authorization header of the REGISTER request did not contain an "integrity protected" parameter, or contained 
the "integrity-protected" parameter was set to the value "no", the S-CCF shall apply the procedures described in 
subclause 5.4.1.2.1. 

On completion of the above procedures in this subclause and of the Cx Server Assignment procedure with the HSS, as 
described in 3GPP TS 29.228 [14], for one or more public user identities, the S-CCF shall update or remove those 
public user identities, their registration state and the associated service profiles from the local data (based on operators' 
policy the S-CCF can request of the HSS to either be kept or cleared as the S-CCF allocated to this subscriber). 

5.4.1 .5 Network-initiated deregistration 

NOTE 1: A network-initiated deregistration event that occurs at the S-CSCF may be received from the HSS or may 
be an internal event in the S-CSCF. 

Prior to initiating the network-initiated deregistration for the only currently registered public user identity and its 
associated set of imphcitly registered pubhc user identities and wildcarded pubhc user identities that have been 
registered with the same contact (i.e. no other pubhc user identity is registered with this contact) while there are still 
active multimedia sessions belonging to this contact, the S-CSCF shall release only the multimedia sessions belonging 
to this contact as described in the following paragraph. The multimedia sessions for the same public user identity, if 
registered with another contact remain unchanged. 

Prior to initiating the network-initiated deregistration while there are still active multimedia sessions that are associated 
with this user and contact, the S-CSCF shall release none, some or all of these multimedia sessions by applying the 
steps Usted in subclause 5.4.5.1.2 under the following conditions: 

when the S-CSCF does not expect the UE to reregister (i.e. S-CSCF will set the event attribute within the 
<contact> element to "rejected" for the NOTIFY request, as described below), the S-CSCF shall release all 
sessions that are associated with the registered contact address for the pubhc user identities being deregistered, 
which includes the implicitly registered public user identities. 

when the S-CSCF expects the UE to reregister (i.e. S-CSCF will set the event attribute within the <contact> 
element to "deactivated" for the NOTIFY request, as described below), the S-CSCF shall only release sessions 
that currently include the user 's contact address , where the session was initiated by or terminated towards the 
user with the contact address registered to one of the pubhc user identities being deregistered, which includes the 
implicitly registered public user identities. 
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When a network-initiated deregistration event occurs for one or more public user identities that are bound to one or 
more contacts, the S-CSCF shall send a NOTIFY request to all subscribers that have subscribed to the respective reg 
event package. For each NOTIFY request, the S-CSCF shall: 

1) set the Request-URI and Route header to the saved route information during subscription; 

2) set the Event header to the "reg" value; 

3) in the body of the NOTIFY request, include as many <registration> elements as many public user identities the 
S-CSCF is aware of the user owns; 

4) set the aor attribute within each <registration> element to one public user identity: 

a) set the <uri> sub-element inside the <contact> sub-element of each <registration> element to the contact 
address provided by the UE; 

b) if the public user identity: 

i) has been deregistered then: 

set the state attribute within the <registration> element to "terminated"; 

- set the state attribute within the <contact> element to "terminated"; and 

set the event attribute within the <contact> element to "deactivated" if the S-CSCF expects the UE to 
reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or 

ii) has been kept registered then: 

I) set the state attribute within the <registration> element to "active"; 

II) set the state attribute within the <contact> element to: 

for the contact address to be removed set the state attribute within the <contact> element to 
"terminated", and event attribute element to "deactivated" if the S-CSCF expects the UE to 
reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or 

- for the contact address which remain unchanged, if any, leave the <contact> element unmodified, 
and if the contact has been assigned GRUUs set the <pub-gruu> and <temp-gruu> sub-elements of 
the <contact> element as specified in draft-ietf-sipping-gruu-reg-event [94] and include the 
<unknown-parani> sub-element within each <contact> to any additional header parameters 
contained in the Contact header of the REGISTER request according to RFC 3680 [43]; and 

NOTE 2: There might be more than one contact information available for one public user identity. When 
deregistering this UE, the S-CSCF wiU only modify the <contact> elements that were originally 
registered by this UE using its private user identity. The <contact> elements of the same public user 
identitity, if registered by another UE using different private user identities remain unchanged. 

5) add a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]. 
The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. 

When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" 
(i.e. all public user identities have been deregistered or expired), the S-CSCF shall also terminate the subscription to the 
registration event package by setting the Subscription-State header to the value of "terminated". 

Also, for all service profiles in the implicit registration set the S-CSCF shall send a third-party REGISTER request, as 
described in subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS as if a 
equivalent REGISTER request had been received from the user deregistering that public user identity, or combination 
of pubUc user identities. 

In case of the deregistration of the old contact information when the UE is roaming, registration is done in a new 
network and the previous registration has not expired, on completion of the above procedures, the S-CSCF shall remove 
the registration information related to the old contact from the local data. 
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Otherwise, on completion of the above procedures for one or more public user identities linked to the same private user 
identity, the S-CSCF shall deregister those public user identities and the associated implicitly registered public user 
identities. On completion of the Cx Server Assignment procedure with the HSS, as described in 3GPP TS 29.228 [14], 
the S-CSCF shall update or remove those pubUc user identities Unked to the same private user identity, their registration 
state and the associated service profiles from the local data (based on operators' policy the S-CSCF can request of the 
HSS to either be kept or cleared as the S-CSCF allocated to this subscriber). On the completion of the Cx Registration- 
Termination procedure with the HSS, as described in 3GPP TS 29.228 [14], the S-CSCF shall remove those pubUc user 
identities, their registration state and the associated service profiles from the local data. 



5.4.1.6 Network-initiated reauthentication 

The S-CCF may request a subscriber to reauthenticate at any time, based on a number of possible operator settable 
triggers as described in subclause 5.4.1.2 or subclause 5.4.1.2A . 

If the S-CCF is informed that a private user identity needs to be re-authenticated, the S-CCF shall generate a NOTIFY 
request on all dialogs which have been established due to subscription to the reg event package of that user. For each 
NOTIFY request the S-CCF shall: 

1) set the Request-URI and Route header to the saved route information during subscription; 

2) set the Event header to the "reg" value; 

3) in the body of the NOTIFY request, include as many <registration> elements as many public user identities the 
S-CCF is aware of the user owns: 

a) set the <uri> sub-element inside the <contact> sub-element of each <registration> element to the contact 
address provided by the UE; 

b) set the aor attribute within each <registration> element to one public user identity; 

c) set the state attribute within each <registration> element to "active"; 

d) set the state attribute within each <contact> element to "active"; 

e) set the event attribute within each <contact> element that was registered by this UE to "shortened"; 

f) set the expiry attribute within each <contact> element that was registered by this UE to an operator defined 
value; and 

g) set the <pub-gruu> and <temp-gruu> sub-elements within each <contact> element as specified in 
subclause 5.4.2.1.2; and 

NOTE 1: There might be more than one contact information available for one public user identity. The S-CCF will 

only modify the <contact> elements that were originally registered by this UE using its private user 
identity. The S-CCF will not modify the <contact> elements for the same public user identity, if 
registered by another UE using different private user identity. 

4) set a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17]. 
Afterwards the S-CCF shall wait for the user to reauthenticate (see subclause 5.4.1.2 and subclause 5.4.1.2A) . 

NOTE 2: Network initiated re-authentication may occur due to internal processing within the S-CCF. 
The S-CCF shall only include the non-barred public user identities in the NOTIFY request. 

When generating the NOTIFY request, the S-CCF shall shorten the validity of all registration lifetimes associated with 
this private user identity to an operator defined value that will allow the user to be re-authenticated. 
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5.4.1 .7 Notification of Application Servers about registration status 

During registration, the S-CCF shall include a P- Access-Network-Info header and a P-Visited-Network-ID header (as 
received in the REGISTER request from the UE) in the 3rd-party REGISTER sent towards the ASs, if the AS is part of 
the trust domain. If the AS is not part of the trust domain, the S-CCF shall not include any P-Access-Network-Info 
header or P-Visited-Network-ID header. The S-CCF shall not include a P-Access-Network-Info header in any responses 
to the REGISTER request. 

If the registration procedure described in subclauses 5.4.1.2, 5.4.1.2A, 5.4.1.4 or 5.4.1.5 (as appropriate) was successful, 
the S-CCF shall send a third-party REGISTER request to each AS with the following information: 

a) the Request-URl, which shall contain the AS's SIP URI; 

b) the From header, which shall contain the S-CCF's SIP URI; 

c) the To header, which shall contain a non-barred public user identity belonging to the service profile of the 
processed Filter Criteria. It may be either a public user identity as contained in the REGISTER request received 
from the UE or one of the implicitly registered public user identities, in the service profile as configured by the 
operator; 

NOTE 1 : For the whole implicit registration set only one public user identity per service profile appears in the 

third-party REGISTER requests. Thus, based on third-party REGISTER requests only, the ASs will not 
have complete information on the registration state of each public user identity in the implicit registration 
set. The only way to have a complete and continuously updated information (even upon administrative 
change in subscriber's profile) is to subscribe to the reg event package. 

d) the Contact header, which shall contain the S-CCF's SIP URI; 

e) for initial registration and user-initiated reregistration (subclause 5.4.1.2 or subclause 5.4.1.2A) , the Expires 
header, which shall contain the same value that the S-CCF returned in the 200 (OK) response for the REGISTER 
request received from the UE; 

f) for user-initiated deregistration (subclause 5.4.1.4) and network-initiated deregistration (subclause 5.4.1.5), the 
Expires header, which shall contain the value zero; 

g) for initial registration and user-initiated reregistration (subclause 5.4.1.2 or subclause 5.4. 1.2 A ), a message body, 
if there is Filter Criteria indicating the need to include HSS provided data for the REGISTER event (e.g. HSS 
may provide AS specific data to be included in the third-party REGISTER). If there is a service information 
XML element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then the S-CCF shaU 
include it in the message body of the REGISTER request within the <service-info> XML element as described 
in subclause 7.6. For the messages including the IM CN subsystem XML body, the S-CCF shall set the value of 
the Content-Type header to include the MIME type specified in subclause 7.6; 

h) for initial registration and user-initiated reregistration, the P-Charging- Vector header, shall contain the same icid 
parameter that the S-CCF received in the original REGISTER request from the UE. The S-CCF shall insert a 
type 3 orig-ioi parameter in the P-Charging- Vector header. The type 3 orig-ioi parameter identifies the sending 
network of the request and add a type 3 orig-ioi parameter before the received orig-ioi parameter. The S-CCF 
shall set the type 3 orig-ioi parameter to a value that identifies the sending network of the request. The S-CCF 
shall not include the type 3 term-ioi parameter; 

i) for initial registration and user-initiated reregistration, a P-Charging-Function- Addresses header, which shall 
contain the values received from the HSS if the message is forwarded within the S-CCF home network; and 

j) in case the original received REGISTER request contained a P-User-Database header and the AS belongs to the 
same operator as the S-CCF, optionally a P-User-Database header which shall contain the received value. 

When the S-CCF receives any response to a third-party REGISTER request, the S-CCF shall store the value of the 
term-ioi parameter received in the P-Charging-Vector header, if present. 

NOTE 2: Any received term-ioi parameter will be a type 3 term-ioi. The type 3 term-ioi identifies the service 
provider from which the response was sent. 

When the S-CCF receives any response to third-party REGISTER, the S-CCF shall store the value of the type 3 term-ioi 
parameter received in the P-Charging- Vector header, if present. The type 3 term-ioi identifies the service provider from 
which the response was sent. 
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If the S-CCF fails to receive a SIP response or receives a 408 (Request Timeout) response or a 5xx response to a third- 
party REGISTER, the S-CCF shall: 

- if the default handhng defined in the filter criteria indicates the value "SESSION_CONTINUED" as specified in 
3GPP TS 29.228 [14] or no default handling is indicated, no further action is needed; and 

- if the default handhng defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified 
in 3GPP TS 29.228 [14], the S-CCF shall, for a currently registered public user identity, initiate the network- 
initiated deregistration as described in subclause 5.4.1.5. 

5.4.1 .8 Service profile updates 

NOTE 1: The S-CSCF can receive an update of subscriber data notification on the Cx interface, from the HSS, 
which can affect the stored information about served public user identities. According to 
3GPP TS 29.228 [14], the changes are guaranteed not to affect the default public user identity within the 
registration implicit set. 

When receiving a Push-Profile-Request (PPR) from the HSS (as described in 3GPP TS 29.228 |14|), modifying the 
service profile of served public user identities, the S-CSCF shall 

1) if the modification consists in the addition of a new non-barred public user identity to an implicit set, or in the 
change of status from barred to non-barred for a public user identity already in the implicit set, add the public 
user identity to the list of registered, non-barred public user identities; 

2) if the modification consists in the deletion or in the change of status from non-barred to barred of a public user 
identity in an implicit set, remove the pubhc user identity from the list of registered, non-barred pubhc user 
identities; 

NOTE 2: As the S-CSCF checks the barring status of the public user identity on receipt of a initial request for a 
dialog, or a standalone transaction, the above procedures have no impact on transactions or dialogs 
already in progress and are effective only for new transactions and dialogs. 

3) if the modification consists of deletion of a public user identity from an implicit registration set while there are 
active multimedia session belonging to this public user identity and contact, the S-CSCF shall perform the 
network initiated deregistration procedures as described in sub-clause 5.4.1.5 and skip synchronization of the UE 
and IM CN entitities as described in step 4; and 

4) synchronize with the UE and IM CN entities, by either: 

When receiving a Push Profile Request (PPR) from the HSS (as described in 3GPP TS 29.228 [14]), modifying the 
service profile of served pubhc user identities, the S CSCF shall synchronize with the UE and IM CN entities, by either: 

- performing the procedures for notification of the reg-event subscribers about registration state, as described 
in subclause 5.4.2.1.2; or 

- triggering the UE to re-register, by shortening the life time of the current registration, as described in 
subclause 5.4.1.6. 

If the modirication of the service profile consists in the addition of a new non barred public user identity to an implicit 
set, or in the change of status from barred to non barred for a public user identity already in the implicit set, the S CSCF 
shall add the public user identity to the hst of registered, non barred public user identities. 

If the modification of the service profile consists in the deletion or in the change of status from non barred to barred of a 
pubhc user identity in an implicit set, the S CSCF shall remove the public user identity from the hst of registered, non 
barred public user identities. 

NOTE 2: As the S CSCF checks the barring status of the pubhc user identity on receipt of a initial request for a 
dialog, or a standalone transaction, the above procedures have no impact on transactions or dialogs 
already in progress and are effective only for new transactions and dialogs. 
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5.4.2.1 .2 Notification about registration state 

When sending a NOTIFY request, the S-CSCF shall not use the default filtering policy as specified in RFC 3680 [43], 
i.e. the S-CSCF shall always include in every NOTIFY request the state information of all registered public user 
identities of the user (i.e. the fuU state information). 

NOTE 1 : Contact information related to emergency registration is not included. 

When generating NOTIFY requests, the S-CSCF shall not preclude any valid reg event package parameters in 
accordance with RFC 3680 [43]. 

For each NOTIFY request on all dialogs which have been established due to subscription to the reg event package of 
that user, the S-CSCF shall: 

1) set the Request-URI and Route header to the saved route information during subscription; 

2) set the Event header to the "reg" value; 

3) in the body of the NOTIFY request, include one <registration> elements for each public user identity that the S- 
CSCF is aware the user ovras. 

If the user shares one or more public user identities with other users, any contact addresses registered by other 
users of the shared public user identity shall be included in the NOTIFY request; 

4) for each <registration> element: 

a) set the aor attribute to one public user identity; 

b) set the <uri> sub-element inside each <contact> sub-element of the <registration> element to the contact 
address provided by the respective UE as follows: 

I) if the aor attribute of the <registration> element contains a SIP sip or sips URI, then for each contact 
address that contains a +sip.instance header parameter, include <pub-gruu> and <temp-gruu> sub- 
elements within the corresponding <contact> element. The S-CSCF shall set the contents of these 
elements as specified in drart-ietr-sipping-griiii-reg-event |94| shall contain, respectively, the public and 
temporary GRUUs representing (as specified in subclause 5. 4. 7 A) the association between the aor 
attribute of the <registration> element and the instance ID contained in the + sip.instance parameter ; or 

II) if the aor attribute of the <registration> element contains a tel-URI, determine its alias SIP URI and then 
include a copy of the <pub-gruu> and <temp-gruu> sub-elements from that equivalent element; and 

c) if the public user identityset at step a): 

I) has been deregistered (i.e. no active contact left) then: 

- set the state attribute within the <registration> element to "terminated" ; 
set the state attribute within each <contact> element to "terminated"; and 

- set the event attribute within each <contact> element to "deactivated", "expired", "unregistered", 
"rejected" or "probation" according to RFC 3680 [43]. 

If the public user identity has been deregistered and the deregistration has already been indicated in the 
NOTIFY request, and no new registration has occurred, its <registration> element shall not be included in 
the subsequent NOTIFY requests; or 

II) has been registered then: 

set the <unknown-param> element to any additional header parameters contained in the contact 
header of the REGISTER request according to RFC 3680 [43]; 

- set the state attribute within the <registration> element to "active", if not already set to "active", 
otherwise leave it unchanged; and: 

- set the state attribute within the <contact> element to "active"; and set the event attribute within the 
<contact> element to "registered"; or 
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III) has been re-registered then: 

set the <unknown-param> element to any additional header parameters contained in the contact 
header of the REGISTER request according to RFC 3680 [43]; 

- for contact addresses to be registered: set the state attribute within the <contact> element to "active"; 
and set the event attribute within the <contact> element to "registered"; or 

- for contact addresses to be re-registered, set the state attribute within the <contact> element to 
"active"; and set the event attribute within the <contact> element to "refreshed" according to 
RFC 3680 [43]; or 

- for contact addresses that remain unchanged, if any, leave the <contact> element unmodified; or 

IV) has been automatically registered, and has not been previously automatically registered: 

- set the <unknown-param> element to any additional header parameters contained in the contact 
header of the originsl REGISTER request according to RFC 3680 [43]; 

- set the state attribute within the <registration> element to "active"; 

- set the state attribute within the <contact> element to "active"; and 

- set the event attribute within the <contact> element to "created" ;-aHd 

V) is hosted (unregistered case) at the S-CSCF: 

set the state attribute within the <registration> element to "terminated"; 

- set the state attribute within each <contact> element to "terminated"; and 

- set the event attribute within each <contact> element to "unregistered" . 

The S-CSCF shall also terminate the subscription to the registration event package by setting the 
Subscription-State header to the value of "terminated"; and 

5) set the P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.260 [17] and a 
type 3 orig-ioi parameter. The S-CSCF shall set the type 3 orig-ioi parameter to a value that identifies the 
sending network of the request. The S-CSCF shall not include the type 3 term-ioi parameter. 

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. 

EXAMPLE: If sip:userl_publicl @homel .net is registered, the public user identity 

sip:userl_public2@homel.net can automatically be registered. Therefore the entries in the body of 
the NOTIFY request look like: 

<?xml version="l . 0" ?> 

<reginf o xmlns= "urn : ietf : params : xml : ns : reginf o" 
version="0" state= " f ull " > 
<registration aor=" sip : userl publicl@homel .net " id="as9" 
state="active" > 
<contact id="76" state="active" event="registered"> 
<uri>sip : [5555 : : aaa :bbb : ccc : ddd] </uri> 
<unknown-param name= "audio" /> 
</contact> 
</registration> 

<registration aor= " sip : userl_public2@homel . net " id="aslO" 
state="active" > 
<contact id="86" state="active" event=" created" > 
<uri>sip: [5555 : :aaa:bbb : ccc : ddd] </uri> 
<unknown-param name= "audio" /> 
</contact> 
</registration> 
</reginf o> 

When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" 
(i.e. all public user identities have been deregistered^ e^expired or are hosted (unregistered case) at the S-CSCF ), the S- 
CSCF shall also terminate the subscription to the registration event package by setting the Subscription-State header to 
the value of "terminated". 
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When all of a UE's contact addresses have been deregistered (i.e. there is no <contact> element set to "active" for this 
UE), the S-CSCF shall consider subscription to the reg event package belonging to the UE cancelled (i.e. as if the UE 
had sent a SUBSCRIBE request with an Expires header containing a value of zero). 

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. 

When the S-CSCF receives any response to the NOTIFY request, the S-CSCF shall store the value of the term-ioi 
parameter received in the P-Charging- Vector header, if present. 

NOTE 2: Any received term-ioi parameter will be a type 3 term-ioi. The type 3 term-ioi identifies the service 
provider from which the response was sent. 

5.4.3.2 Requests initiated by the served user 

When the S-CCF receives from the served user or from a PSI an initial request for a dialog or a request for a standalone 
transaction, and the request is received either from a functional entity within the same trust domain or contains a vaUd 
original dialog identifier (see step 3) or the dialog identifier (From, To and Call-ID header fields) relates to an existing 
request processed by the S-CCF, then prior to forwarding the request, the S-CCF shall: 

1) determine whether the request contains a barred public user identity in the P-Asserted-Identity header field of the 
request or not. In case the said header field contains a barred public user identity for the user, then the S-CCF 
shall reject the request by generating a 403 (Forbidden) response. Otherwise, continue with the rest of the steps; 

NOTE 1: If the P-Asserted-Identity header field contains a barred public user identity, then the message has been 
received, either directly or indirectly, from a non-compliant entity which should have had generated the 
content with a non-barred public user identity. 

lA) if the Contact is a GRUU, but is not valid as defined in subclause 5.4.7A.4, then return a 4xx response as 
specified in draft-ietf-sip-gruu [93]; 

2) store the value of the orig-ioi parameter received in the P-Charging-Vector header if present, and remove it from 
any forwarded request; 

NOTE 2: Any received orig-ioi parameter will be a type 3 orig-ioi. The type 3 orig-ioi identifies the service 
provider from which the request was sent (AS initiating a session on behalf of a user or a PSI); 

3) check if an original dialog identifier that the S-CCF previously placed in a Route header is present in the topmost 
Route header of the incoming request. If not present, the S-CCF shall build an ordered list of initial filter criteria 
based on the public user identity in the P-Asserted-Identity header of the received request as described in 
3GPP TS 23.218 [5]. If present, the request has been sent from an AS in response to a previously sent request, an 
ordered Ust of initial filter criteria already exists and it shall be kept imchanged even if the AS has changed the P- 
Asserted-Identity header; 

4) remove its own SIP URI from the topmost Route header; 

4A) if there was an original dialog identifier present in the topmost Route header of the incoming request and the 
request is received from a functional entity within the same trust domain and contains a P-Asserted-Service 
header field, continue the procedure with step 5; 

4A) — determine whether the contents of the request matches a subscribed service (i.e. SDP media capabilities. 
Content Type header field) for each and any of the subscribed services for the served user. As an operator 
option, if the contents of the request do not match a subscribed service, the S CCF may reject the request by 
generating a 103 (Forbidden) response. Otherwise, continue with the rest of the steps; 

Editor's note: It is for further study whether the S CCF shall authorise and pohce that the media types used by the 
served user is consistent with the ICSI value. 

4B) — determine whether the contents of the request matches a subscribed service (i.e. SDP media capabilities. 
Content Type header field) for each and any of the subscribed services for the served user. As an operator 
option, if the contents of the request do not match a subscribed service, the S CSCF may reject the request by 
generating 3-103 (Forbidden) response. Otherwise, continue with the rest of the steps; 

4G) — if the request contains a P Preferred Service header field check whether the ICSI value contained in the 
P Preferred Service header field is part of the set of the subscribed services for the served user and if so then use 
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that ICSI value as the value for the P Asserted Header field for the request and remove the P Preferred Service 

header field; 

4B) if the request contains a P-Preferred-Service header field, check whether the ICSI value contained in the P- 
Preferred-Service header field is part of the set of the subscribed services for the served user and determine 
whether the contents of the request (e.g. SDP media capabilities, Content-Type header field) match the ICSI for 

the subscribed service; 

a) if not, as an operator option, the S-CSCF may re ject the request by generating a 403 (Forbidden) response. 
Otherwise remove the P-Preferred-Service header field and conlinue with the rest of the steps; 

b) if so. and if the request is related to an IMS communication service and the IMS communication service 
requires the use of an ICSI value then then include a P-Asserted-Service header field in the request 
containing the ICSI value contained in the P-Preferred-Service header field, remove the P-Preferred-Service 
header field, and continue the procedure with step 5; 

c) if so. and if the request is related to an IMS communication service and the IMS communication service does 
not require the use of an ICSI value then continue without including an ICSI value; and 

d) if so. and if the request does not relate to an IMS communication service (or if the S-CSCF is unable to 
unambiguously determine the service being requested but decides to allow the session to continue) then 
continue without inclding an ICSI value; 

4B) — if the request does not contain a P Preferred Service header field or the ICSI value contained in a 

P Preferred Service header field is not part of the set of the subscribed services for the served user then as an 
operator option, the S CCF may reject the request by generating a ^03 (Forbidden) response. Otherwise, 
continue with the rest of the steps; 

4E) if the the request does not contain a P Preferred Service header field or the ICSI value contained in a P 

Preferred Service header field is not part of the set of the subscribed services for the served user then if the 
contents of the request are allowed by the subscribed services for the served user select an ICSI value for the 
related IMS communication service; 

4C) if the request does not contain a P-Preferred-Service header field, check whether the contents of the request 
match a subscribed service for each and any of the subscribed services for the served user; 

a) if not, as an operator option, the S-CSCF may reject the request by generating a 403 (Forbidden) response; 
and 

b) if so. select an ICSI value for the related IMS communication service and include a P-Asserted-Service 
header field in the request containing the selected ICSI value; 

'1F)include a P Asserted Service header field in the request containing the ICSI value determined in step -IB and use 
as a header field in the initial request when matching initial filter criteria in step 5; 

5) check whether the initial request matches the next unexecuted initial filter criteria from the ordered list of initial 
filter criteria, and if it does, the S-CCF shall: 

a) insert the AS URI to be contacted into the Route header as the topmost entry followed by its own URI 
populated as specified in the subclause 5.4.3.4; 

b) if the AS is located outside the trust domain then the S-CCF shall remove the P Access Network Info header 
field and its values in the request and the access-network-charging-info parameter in the P-Charging- Vector 
header from the request that is forwarded to the AS; if the AS is located within the trust domain, then the 
S-CCF shall retain the P Access Network Info header field and its values and the access-network-charging- 
info parameter in the P-Charging- Vector header in the request that is forwarded to the AS; and 

c) insert a type 3 orig-ioi parameter before the received orig-ioi parameters in the P-Charging- Vector header. 
The S-CCF shall set the type 3 orig-ioi parameter to a value that identifies the sending network of the request. 
The S-CCF shall not include the type 3 term-ioi parameter; 

NOTE 3: Depending on the result of processing the filter criteria the S-CCF might contact one or more AS(s) 
before processing the outgoing Request URI. 
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NOTE 4: An AS can activate or deactivate its own filter criteria via the Sh interface. As the S-CCF checks initial 
filter criteria only on receipt of an initial request for a dialog, or a standalone transaction, a modified 
service profile will have no impact on transactions or dialogs already in progress and the modified profile 
will be effective only for new transactions and dialogs. If the S-CCF receives a modification of the iPC 
during their execution, then it should not update the stored initial Filter Criteria until the iFC related to the 
initial request have been completely executed. 

6) if there is no original dialog identifier present in the topmost Route header of the incoming request store the 
value of the icid parameter received in the P-Charging- Vector header and retain the icid parameter in the 
P-Charging-Vector header. Optionally, the S-CCF may generate a new, globally unique icid and insert the new 
value in the icid parameter of the P-Charging- Vector header when forwarding the message. If the S-CCF creates 
a new icid, then it is responsible for maintaining the two icid values in the subsequent messaging; 

7) in step 5, if the initial request did not match the next unexecuted initial filter criteria (i.e. the request is not 
forwarded to an AS), insert an orig-ioi parameter into the P-Charging-Vector header. The S-CCF shall set the 
orig-ioi parameter to a value that identifies the sending network. The S-CCF shall not include the type 2 term-ioi 
parameter; 

8) if there is no original dialog identifier present in the topmost Route header of the incoming request insert a 
P-Charging-Function-Addresses header populated with values received from the HSS if the message is 
forwarded within the S-CCF home network, including towards AS; 

9) if there is no original dialog identifier present in the topmost Route header of the incoming request and if the 
S-CCF has knowledge that the SIP URI contained in the received P-Asserted-Identity header is an alias SIP URI 
for a tel URI, add a second P-Asserted-Identity header containing this tel-URI, including the display name 
associated with the tel URI, if available. If the P-Asserted-Identity header contains only a tel URI, the S-CCF 
shall add a second P-Asserted-Identity header containing a SIP URI. The added SIP URI shall contain in the user 
part a "+" followed by the international public telecommunication number contained in tel URI, and user's home 
domain name in the hostport part. The added SIP URI shall contain the same value in the display name as 
contained in the tel URI. The S-CCF shall also add a user parameter equals "phone" to the SIP URI; 

NOTE 5: The S-CSCF recognizes that a given SIP URI is an alias SIP URI of a tel URI, since they have the same 
service profile and belong to the same set of imphcitly registered public user identities this grouping is 
sent from the HSS (see 3GPP TS 29.228 [141) . If tel URI is shared URI so is the alias SIP URI. 

10) if the request is not forwarded to an AS and if the outgoing Request-URI is: 

- a SIP URI with the user part starting with a + and the user parameter equals "phone", and if configured per 
local operator poUcy, the S-CCF shall perform the procedure described here. Local policy can dictate 
whether this procedure is performed for all domains of the SIP URI, only if the domain belongs to the home 
network, or not at all. If local policy indicates that the procedure is to be performed, then the S-CCF shall 
translate the international public telecommunications number contained in the user part of the SIP URI (see 
RFC 3966 [22]) to a globally routeable SIP URI using either an ENUM/DNS translation mechanism with the 
format specified in RFC 3761 [24], or any other available database. Database aspects of ENUM are outside 
the scope of the present document. An S-CCF that implements the additional routeing functionality described 
in annex I may forward the request without attempting translation. If a translation is in fact performed and it 
succeeds, the S-CCF shall update the Request-URI with the globally routeable SIP URI returned by 
ENUM/DNS. If this translation fails, the request may be forwarded to a BGCF or any other appropriate entity 
(e.g. a MRFC to play an announcement) in the originator's home network or the S-CCF may send an 
appropriate SIP response to the originator. When forwarding the request to a BGCF or any other appropriate 
entity, the S-CCF shall leave the original Request-URI containing the SIP URI with user parameter equals 
phone unmodified. If the request is forwarded, the S-CCF shall remove the access-network-charging-info 
parameter from the P-Charging- Vector header prior to forwarding the message; 

- a tel URI in the international format, the S-CCF shall translate the E. 164 address (see RFC 3966 [22]) to a 
globally routeable SIP URI using either an ENUM/DNS translation mechanism with the format specified in 
RFC 376 1[ 24] , or any other available database. Databases aspects of ENUM are outside the scope of the 
present document. An S-CCF that implements the additional routeing functionaUty described in annex I may 
forward the request without attempting translation. If this translation is in fact performed and it succeeds, the 
S-CCF shall update the Request-URI with the globally routeable SIP URI returned by ENUM/DNS. If this 
translation fails, the request may be forwarded to a BGCF or any other appropriate entity (e.g. a MRFC to 
play an announcement) in the originator's home network or the S-CCF may send an appropriate SIP response 
to the originator. When forwarding the request to a BGCF or any other appropriate entity, the S-CCF shall 
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leave the original Request-URI containing the tel URI unmodified. If the request is forwarded, the S-CCF 
shall remove the access-network-charging-info parameter from the P-Charging- Vector header prior to 
forwarding the message; 

- a tel URI in non-international format (i.e. the local service number analysis and handling is either failed in 
the appropriate AS or the request has not been forwarded to AS for local service number analysis and 
handling at all), either forward the request to a BGCF or any other appropriate entity (e.g. a MRFC to play an 
announcement) in the originator's home network or send an appropriate SIP response to the originator; and 

- a pres URI or an im URI, the S-CCF shall forward the request as specified in RFC 3861 [63]. In this case, the 
S-CCF shall not modify the received Request-URI; 

1 l)determine the destination address (e.g. DNS access) using the URI placed in the topmost Route header if present, 
otherwise based on the Request-URI. If the destination requires interconnect functionahties (e.g. the destination 
address is of an IP address type other than the IP address type used in the IM CN subsystem), the S-CCF shall 
forward the request the request shall be forwarded to the destination address via an IBCF in the same network; 

12) if network hiding is needed due to local policy, put the address of the IBCF to the topmost route header; 

13) in case of an initial request for a dialog: 

a) determine the need for GRUU processing. GRUU processing is required if: 

- an original dialog identifier that the S-CCF previously placed in a Route header is not present in the 
topmost Route header of the incoming request (this means the request is not returning after having been 
sent to an AS), and 

- the contact address contains a valid GRUU as specified in subclause 5.4.7A.4. 

b) if GRUU processing is not required and the initial request originated from a served user, then determine the 
need to record-route for other reasons: 

if the request is routed to an AS which is part of the trust domain, the S-CCF can decide whether to 
record-route or not. The decision is configured in the S-CCF using any information in the received 
request that may otherwise be used for the initial filter criteria. If the request is record-routed the S-CCF 
shall create a Record-Route header containing its own SIP URI; or 

- if the request is routed elsewhere, create a Record-Route header containing its own SIP URI; 

NOTE 6: For requests originated from a PSI the S-CCF can decide whether to record-route or not based on operator 
policy. 

c) if GRUU processing is required, the S-CCF shall create a Record-Route header containing its own SIP URI; 

d) if GRUU processing is required, the S-CCF shall save an indication that GRUU-routeing is to be performed 
for in-dialog requests that reach the S-CCF because of the Record-route header added in step c); 

NOTE 7: The manner of representing the GRUU-routeing indication is a private matter for the S-CCF. The 

indication is used during termination processing of in-dialog requests to cause the S-CCF to replace a 
Request-URI containing a GRUU with the corresponding registered contact address. It can be saved using 
values in the Record-Route header, or in dialog state. 

14) based on the destination user (Request-URI), remove the P-Access-Network-lnfo header and the 
access-network-charging-info parameter in the P-Charging-Vector header prior to forwarding the message; 

15) route the request based on SIP routeing procedures; and 

16) if the request is an INVITE request, save the Contact, Cseq and Record-Route header field values received in the 
request such that the S-CCF is able to release the session if needed. 

When the S-CCF receives, an initial request for a dialog or a request for a standalone transaction, from an AS acting on 
behalf of an unregistered user, the S-CCF shall: 

1) execute the procedures described in the steps 1, 2, 3, 4, 4A, 4B, 4C, 4D, 4E, 4F, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 
15 and 16 in the above paragraph (when the S-CCF receives, from a registered served user, an initial request for 
a dialog or a request for a standalone transaction). 
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NOTE 8: When the S-CCF does not have the user profile, before executing the actions as Hsted above, it initiates 
the S-CCF Registration/deregistration notification with the purpose of downloading the relevant user 
profile (i.e. for unregistered user) and informs the HSS that the user is unregistered. The S-CCF will 
assess triggering of services for the unregistered user, as described in 3GPP TS 29.228 [14]. 

If the S-CCF fails to receive a SIP response or receives a 408 (Request Timeout) response or a 5xx response from the 
AS, the S-CCF shall: 

- if the default handUng defined in the filter criteria indicates the value "SESSION_CONTINUED" as specified in 
3GPP TS 29.228 [14] or no default handling is indicated, execute the procedure from step 4; and 

if the default handling defined in the filter criteria indicates the value "SESSION_TERMINATED" as specified 
in 3GPP TS 29.228 [14], either forward the received response or, if the request is an initial INVITE request, send 
a 408 (Request Timeout) response or a 5xx response towards the served UE as appropriate (without verifying the 
matching of filter criteria of lower priority and without proceeding for further steps). 

If the S-CCF receives any final response from the AS, it shall forward the response towards the served UE (without 
verifying the matching of filter criteria of lower priority and without proceeding for further steps). 

When the S-CCF receives any response to the above request, the S-CCF may: 

1) apply any privacy required by RFC 3323 [33] and RFC 3325 [34] to the P-Asserted-Identity header , although the 
S-CCF shall not, except for the case where trust domain provisiorung appUes (e.g. response sent to an AS outside 
the trusted domain) as described in clause 4.4, modify or remove the priv-value set to 'id' within the Privacy 
header. 

NOTE 9: The P-Asserted-Identity header would normally only be expected in Ixx or 2xx responses. 

NOTE 10: The optional procedure above is in addition to any procedure for the application of privacy at the edge of 
the trust domain specified by RFC 3325 [34]. 

NOTE 10a: The priv-value 'id' in the Privacy header will be used by the originating UE to distinguish the request of 
TIR by the terminating user as described in TS 183 008 [a]. 

When the S-CCF receives any response to the above request containing a term-ioi parameter, the S-CCF shall store the 
value of the received term-ioi parameter received in the P-Charging-Vector header, if present, and remove all received 
ioi parameters from the forwarded response if next hop is not an AS. 

NOTE 1 1: Any received term-ioi parameter will be a type 2 term-ioi or type 3 term-ioi. The term-ioi parameter 
identifies the sending network of the response message. 

When the S-CCF receives any response to the above request, and forwards it to AS, the S-CCF shall insert a 
P-Charging- Vector header containing the orig-ioi parameter, if received in the request, and a type 3 term-ioi parameter 
in the response. The S-CCF shall set the type 3 term-ioi parameter to a value that identifies the sending network of the 
response and the type 3 orig-ioi parameter is set to the previously received value of type 3 orig-ioi. 

When the S-CCF receives any Ixx or 2xx response to the initial request for a dialog, if the response corresponds to an 
INVITE request, the S-CCF shall save the Contact and Record-Route header field values in the response in order to be 
able to release the session if needed. 

When the S-CCF, upon sending an initial INVITE request that includes an IP address in the SDP offer (in "c=" 
parameter), receives an error response indicating that the IP address type is not supported, (e.g., the S-CCF receives the 
488 (Not Acceptable Here) with 301 Warning header indicating "incompatible network address format"), the S-CCF 
shall either: 

- fork the initial INVITE request to the IBCF; or 

- process the error response and forward it using the Via header. 

When the S-CCF receives from the served user a target refresh request for a dialog, prior to forwarding the request the 
S-CCF shall: 

OA) if the dialog is related to an IMS communication service determine whether the contents of the request (e.g. 
SDP media capabihties, Content-Type header field) match the IMS communication service as received as the 
ICSI value in the P-Asserted-Service header in the initial request. As an operator option, if the contents of the 
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request do not match the IMS communication service the S-CSCF may reject the request by generating a status 
code reflecting which added contents are not matching. Otherwise, continue with the rest of the steps; 

1) remove its own URI from the topmost Route header; 

2) create a Record-Route header containing its own SIP URI; 

3) or INVITE dialogs (i.e. dialogs initiated by an INVITE request), save the Contact and Cseq header field values 
received in the request such that the S-CCF is able to release the session if needed; 

4) in case the request is routed towards the destination user (Request-URI) or in case the request is routed to an AS 
located outside the trust domain, remove the P Access Network Info header and the access-network-charging- 
info parameter in the P-Charging- Vector header; and 

5) route the request based on the topmost Route header. 

When the S-CCF receives any Ixx or 2xx response to the target refresh request for an INVITE dialog, the S-CCF shall 
replace the saved Contact and Record-Route header field values in the response such that the S-CCF is able to release 
the session if needed. 

When the S-CCF receives from the served user a subsequent request other than a target refresh request for a dialog, 
prior to forwarding the request the S-CCF shall: 

1) remove its own URI from the topmost Route header; 

2) in case the request is routed towards the destination user (Request-URI) or in case the request is routed to an AS 
located outside the trust domain, remove the P Access Network Info header and the access-network-charging- 
info parameter in the P-Charging- Vector header; and 

3) route the request based on the topmost Route header. 

With the exception of 305 (Use Proxy) responses, the S-CCF shall not recurse on 3xx responses. 

5.4.3.3 Requests terminated at the served user 

When the S-CCF receives, destined for a statically pre-configured PSI or a registered served user, an initial request for a 
dialog or a request for a standalone transaction, prior to forwarding the request, the S-CCF shall: 

1) check if an original dialog identifier that the S-CCF previously placed in a Route header is present in the topmost 
Route header of the incoming request. 

- If present, the request has been sent from an AS in response to a previously sent request. 

If not present, it indicates that the request is visiting the S-CCF for the first time, and in this case the S-CCF 
shall determine whether the request contains a barred public user identity in the Request-URI of the request 
or not. In case the Request URI contains a barred public user identity for the user, then the S-CCF shall reject 
the request by generating a 404 (Not Found) response. Otherwise, continue with the rest of the steps; 

2) remove its own URI from the topmost Route header; 

3) if there was an original dialog identifier present in the topmost Route header of the incoming request then check 
whether the Request-URI matches the saved Request-URI. The Request-URI and saved Request-URI are 
considered a match if the Request-URI is equal to the saved value of the Request-URI, or if the 
Request-URI is a public GRUU and the saved value of the Request-URI is a temporary GRUU and both the 
public and temporary GRUUs represent the same public user identity and instance ID. If there is no match, then: 

a) if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in 
the request such that the S-CCF is able to release the session if needed; and 

b) forward the request based on the topmost Route header or if not available forward the request based on the 
Request-URI (routing based on Request-URI is specified steps 10 through 14 from subclause 5.4.3.2) and 
skip the following steps. 

3 A) if the Request-URI is a GRUU, but is not valid as defined in subclause 5.4.7A.4, then return a 4xx response 
as specified in draft-ietf-sip-gruu [93]; 
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3B) if the Request-URI contains a public GRUU and the saved value of the Request URI is a temporary GRUU, 
then replace the Request-URI with the saved value of the Request-URI; 

3€) — if the request contains a P Asserted Service header field check whether the IMS communication service 
identified by the ICSI value contained in the P Asserted Service header field is allowed by the subscribed 
services for the served user and if not, as an operator option, the S CSCF may reject the request by generating a 
103 (Forbidden) response. Otherwise remove the P Asserted Service header field; 

3C) if the request contains a P-Asserted-Service header field check whether the IMS communication service 
identified by the ICSI value contained in the P-Asserted-Service header field is allowed by the subscribed 
services for the served user; 

a) if so, continue from step 4; and 

b) if not, as an operator option, the S-CSCF may reject the request by generating a 403 (Forbidden) response. 
Otherwise, remove the P-Asserted-Service header field and continue with the rest of the steps; 

3B) if the request does not contain a P Asserted Service header field check if the contents of the request matches 

a subscribed service (i.e. SDP media capabilities, Content Type header field) for each and any of the subscribed 
services for the served user. As an operator option, if the contents of the request do not match a subscribed 
service, the S CCF may reject the request by generating a ^103 (Forbidden) response. Otherwise, continue with 
the rest of the steps; 

3E) if the request does not contain a P Asserted Service header field and if the contents of the request (i.e. SDP 

media capabilities. Content Type header field) are allowed by the subscribed services for the served user include 
a P Asserted Service header field in the request containing the ICSI value for the related IMS communication 
service, and use the as a header field in the initial request when matching initial filter criteria in step ^ ; 

3D) if the request does not contain a P-Asserted-Service header field check if the contents of the request matches 
a subscribed service (e.g. SDP media capabilities, Content-Type header field) for each and any of the subscribed 
services for the served user; 

a) if not, as an operator option, the S-CSCF may reject the request by generating a 403 (Forbidden) response. 
Otherwise, continue with the rest of the steps; 

b) if so, and if the request is related to an IMS communication service and the IMS communication service 
requires the use of an ICSI value then include a P-Asserted-Service header field in the request containing the 
ICSI value for the related IMS communication service, and use it as a header field in the initial request when 
matching initial filter criteria in step 4; 

c) if so. and if the request is related to an IMS communication service and the IMS communication service does 
not require the use of an ICSI value then continue without including an ICSI value; and 

d) if so. and if the request does not relate to an IMS communication service (or if the S-CSCF is unable to 
unambiguously determine the service being requested but decides to allow the session to continue) then 
continue without inclding an ICSI value; 

4) check whether the initial request matches the next unexecuted initial filter criteria based on the public user 
identity identified by the Request-URI in the priority order and apply the filter criteria on the SIP method as 
described in 3GPP TS 23.218 [5] subclause 6.5. If there is a match, then the S-CCF shall: 

- if the Request-URI is a temporary GRUU as defined in subclause 5.4.7A.3, then replace the Request-URI 
with the public GRUU that is associated with the temporary GRUU (i.e. the public GRUU representing the 
same public user identity and instance ID as the temporary GRUU); 

- insert the AS URI to be contacted into the Route header as the topmost entry followed by its own URI 
populated as specified in the subclause 5.4.3.4; and 

insert a type 3 orig-ioi parameter in the P-Charging- Vector header. The type 3 orig-ioi parameter identifies 
the sending network of the request message before the received orig-ioi. The S-CCF shall not include the 
type 3 term-ioi parameter; 

NOTE 1: Depending on the result of the previous process, the S-CCF can may-contact one or more AS(s) before 
processing the outgoing Request-URI. 
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NOTE 2: If the Request-URI of the received terminating request contains a temporary GRUU, then step 4 replaces 
the Request-URI with the associated pubhc GRUU before invoking the AS, and step 3B restores the 
original temporary GRUU when the request is returned from the AS. 

NOTE 3: An AS can activate or deactivate its own filter criteria via the Sh interface. As the S-CCF checks initial 
filter criteria only on receipt of an initial request for a dialog, or a standalone transaction, a modified 
service profile will have no impact on transactions or dialogs already in progress and the modified profile 
will be effective only for new transactions and dialogs. If the S-CCF receives a modification of the iFC 
during their execution, then it should not update the stored initial Filter Criteria until the iFC related to the 
initial request have been completely executed. 

5) if there was no original dialog identifier present in the topmost Route header of the incoming request insert a 
P-Charging-Function- Addresses header field, if not present, populated with values received from the HSS if the 
message is forwarded within the S-CCF home network, including towards AS; 

6) if there was no original dialog identifier present in the topmost Route header of the incoming request store the 
value of the icid parameter received in the P-Charging- Vector header and retain the icid parameter in the 
P-Charging- Vector header; 

7) if there was no original dialog identifier present in the topmost Route header of the incoming request store the 
value of the orig-ioi parameter received in the P-Charging-Vector header, if present, and remove all received ioi 
parameters from the forwarded request if next hop is not an AS; 

NOTE 4: Any received orig-ioi parameter will be a type 2 orig-ioi. or type 3 orig-ioi. The orig-ioi parameter 

identifies the sending network of the request message. 

8) in the case there are no Route headers in the request, create a target set of potential routes from the list of 
preloaded routes saved during registration or re-registration, as described in subclause 5.4.1.2, as follows: 

a) if the Request-URI is a valid GRUU as defined in subclause 5.4.7A.4, then the target set is determined by 
following the procedures for Request Targeting specified in draft-ietf-sip-gruu [93], using the public user 
identity and instance ID derived from the GRUU using the procedures of subclause 5.4.7A; 

b) if the Request-URI is not a GRUU, then the target set is all the registered contacts saved for the destination 

public user identity; 

9) if necessary perform the caller preferences to caller capabiUties matching according to RFC 3841 [56B] to the 
target set; 

NOTE 5: This might eliminate entries and reorder the target set. 

10) in case there are no Route headers in the request: 

a) if there is more than one route in the target set determined in steps 8) and 9) above: 

if the fork directive in the Request Disposition header was set to "no-fork", use the contact with the 
highest qvalue parameter when building the Request-URI. In case no qvalue parameters were provided, 
the S-CCF shall decide locally what contact address to be used to build the target URI ; otherwise 

- fork the request or perform sequential search based on the relative preference indicated by the qvalue 

parameter of the Contact header in the original REGISTER request, as described in RFC3261 [26]. In 
case no qvalue parameters were provided, then the S-CSCF determine the contact address to be used to 
build the target URI as directed by the Request Disposition header as described in RFC 3841 [56B]. If the 
Request-Disposition header is not present, the S-CCF shall decide locally whether to fork or perform 
sequential search among the contact addresses; 

- in case that no route is chosen, return a 480 (Temporarily unavailable) response or another appropriate 
unsuccessful SIP response and terminate these procedures. 

b) If no "loose route" indication has been received, in the service proi'ile of the served public user identity, from 
the HSS during registration ,b uild the Request-URI with the contents of the Contact target URI determined in 
the previous step; 
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c) insert a P-Called-Party-ID SIP header field containing the contents of the Request-URI received in the 
request unless the Request-URI contains a temporary GRUU in which case insert the public GRUU in the 
P-Called-Party-ID; 

d) build the Route header field with the Path values from the chosen route and if "loose route" indication has 
been received gn the service profile of the served user identity, from the HSS during registration, add the 
content of the target URI determined in step a), as last URI of the route ; and 

e) save the Request-URI and the total number of Record-route headers as part of the dialog request state. 

NOTE 6: For each initial dialog request terminated at a served user two pieces of state are maintained to assist in 

processing GRUUs: the chosen contact address to which the request is routed; and the position of an entry 
for the S-CCF in the Record-Route header that will be responsible for GRUU translation, if needed (the 
position is the number of entries in the Ust before the entry was added). The entry wiU be added in step 5) 
of the below procedures for handling S-CCF receipt any Ixx or 2xx response to the initial request for a 
dialog. The S-CCF can record-route multiple times, but only one of those (the last) will be responsible for 
gruu translation at the terminating end. 

11) if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in the 
request such that the S-CCF is able to release the session if needed; 

12) optionally, apply any privacy required by RFC 3323 [33] and RFC 3325 [34] to the P-Asserted-Identity header 
and privacy required by RFC 4244 [66] although the S-CCF shall not, except for the case where trust domain 
provisioning applies (e.g. request sent to an AS outside the trusted domain) as described in clause 4.4, modify or 
remove the priv-value set to 'id' within the Privacy header ; 

NOTE 7: The optional procedure above is in addition to any procedure for the application of privacy at the edge of 
the trust domain specified by RFC 3325 [34]. 

NOTE 7a: The priv-value 'id' in the Privacy header will be used by the terminating UE to distinguish the request of 
OIR by the originating user as described in TS 183 007 [b]. 

13) in case of an initial request for a dialog, either: 

- if the request is routed to an AS which is part of the trust domain, the S-CCF can decide whether to record- 
route or not. The decision is configured in the S-CCF using any information in the received request that may 
otherwise be used for the initial filter criteria. If the request is record-routed the S-CCF shall create a Record- 
Route header containing its own SIP URI; or 

- if the request is routed elsewhere, create a Record-Route header containing its own SIP URI; 
13 A) if the request is routed to the P-CSCF remove the P-User-Database header if present; and 

14) forward the request based on the topmost Route header. 

If the S-CCF fails to receive a SIP response or receives a 408 (Request Timeout) response or a 5xx response from the 
AS, the S-CCF shall: 

- if the default handhng defined in the filter criteria indicates the value "SESSION_CONTINUED" as specified in 
3GPP TS 29.228 [14] or no default handling is indicated, execute the procedure from step 4; and 

- if the default handhng defined in the filter criteria indicates the value " SESSION_TERMINATED" as specified 
in 3GPP TS 29.228 [14], either forward the received response or, if the request is an initial INVITE request, send 
a 408 (Request Timeout) response or a 5xx response towards the originating UE as appropriate (without 
verifying the matching of filter criteria of lower priority and without proceeding for further steps). 

If the S-CCF receives any final response from the AS, it shall forward the response towards the originating UE (without 
verifying the matching of filter criteria of lower priority and without proceeding for further steps). 

When the S-CCF receives any response to the above request and forwards it to AS, the S-CCF shall insert a 
P-Charging- Vector header containing the orig-ioi parameter, if received in the request, and a type 3 term-ioi parameter 
in the response. The S-CCF shall set the type 3 term-ioi parameter to a value that identifies the sending network of the 
response and the orig-ioi parameter is set to the previously received value of orig-ioi. 

NOTE 8: Any received term-ioi parameter will be a type 3 term-ioi. The term-ioi parameter identifies the service 
provider from which the response was sent. 
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When the S-CCF receives, destined for an unregistered user, an initial request for a dialog or a request for a standalone 
transaction, the S-CCF shall: 

1) Void. 

2) execute the procedures described in 1,2, 3, 3C, 3D, 3E, ^, 5, 6, 7, 11, 13; 13A and 14 in the above paragraph 
(when the S-CCF receives, destined for the registered served user, an initial request for a dialog or a request for a 
standalone transaction). 

3) In case that no AS needs to be contacted, then S-CCF shall return an appropriate unsuccessful SIP response. This 
response may be a 480 (Temporarily unavailable) and terminate these procedures. 

NOTE 9: When the S-CCF does not have the user profile, before executing the actions as listed above, it initiates 
the S-CCF Registration/deregistration notification with the purpose of downloading the relevant user 
profile (i.e. for unregistered user) and informs the HSS that the user is unregistered. The S-CCF will 
assess triggering of services for the unregistered user, as described in 3GPP TS 29.228 [14]. When 
requesting the user profile the S-CCF can include the information in the P-Private-Key header in S-CCF 
Registration/deregistration notification. 

Prior to performing S-CCF Registration/Deregistration procedure with the HSS, the S-CCF decides which HSS to 
query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 
3GPP TS 29.228 [14] or use the value as received in the P-User-Database header in the initial request for a dialog or a 
request for a standalone transaction as defined in RFC 4457 [82]. The HSS address received in the response to SLF 
query can be used to address the HSS of the public user identity with further queries. 

When the S-CCF receives any Ixx or 2xx response to the initial request for a dialog (whether the user is registered or 
not), it shall: 

1) if the response corresponds to an INVITE request, save the Contact and Record-Route header field values in the 
response such that the S-CCF is able to release the session if needed; 

2) if the response is not forwarded to an AS (i.e. the response is related to a request that was matched to the first 
executed initial filter criteria), insert a type 2 term-ioi parameter in the P-Charging- Vector header of the outgoing 
response. The type 2 term-ioi is set to a value that identifies the sending network of the response and the orig-ioi 
parameter is set to the previously received value of orig-ioi. Values of orig-ioi and term-ioi in the received 
response are removed; 

3) in the case where the S-CCF has knowledge that the SIP URI contained in the received P-Asserted-Identity 
header is an alias SIP URI for a tel URI the S-CCF shall add a second P-Asserted-Identity header containing this 
tel URI including the display name associated with the tel URI, if available. If the P-Asserted-Identity header 
contains only a tel URI, the S-CCF shall add a second P-Asserted-Identity header containing a SIP URI. The 
added SIP URI shall contain in the user part a "+" followed by the international public telecommunication 
number contained in tel URI, and user's home domain name in the hostport part. The added SIP URI shall 
contain the same value in the display name as contained in the tel URI. The S-CCF shall also add a user 
parameter equals "phone" to the SIP URI; 

4) in case the response is sent towards the originating user, the S-CCF may retain remove the P-Access-Network- 
Info header based on local policy rules and the destination user (Request-URl); and 

5) save an indication that GRUU routeing is to be performed for subsequent requests sent within this same dialog 
if: 

a) there is a record-route position saved as part of the initial dialog request state; and 

b) the contact address in the response is a valid GRUU as specified in subclause 5.4.7A.4. 

NOTE 10:There could be several responses returned for a single request, and the decision to insert or modify the 
Record-Route needs to be applied to each. But a response might also return to the S-CCF multiple times 
as it is routed back through AS. The S-CCF will take this into accoimt when carrying out step 5) to ensure 
that the information is stored only once. 

When the S-CCF receives a response to a request for a standalone transaction (whether the user is registered or not), in 
the case where the S-CCF has knowledge that the SIP URI contained in the received P-Asserted-Identity header is an 
alias SIP URI for a tel URI the S-CCF shall add a second P-Asserted-Identity header containing this tel URI, including 
the display name associated with the tel URI, if available. If the P-Asserted-Identity header contains only a tel URI, the 
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S-CCF shall add a second P-Asserted-Identity header containing a SIP URL The added SIP URI shall contain in the 
user part a "+" followed by the international public telecommunication number contained in tel URI, and user's home 
domain name in the hostport part. The added SIP URI shall contain the same value in the display name as contained in 
the tel URI. The S-CCF shall also add a user parameter equals "phone" to the SIP URI. In case the response is 
forwarded to an AS that is located within the trust domain, the S-CCF shall retain the P Access Network Info header 
and the access-network-charging-info parameter in the P-Charging- Vector header; otherwise, the S-CCF shall remove 
the P Access Network Info header and the access-network-charging-info parameter in the P-Charging- Vector header. 

When the S-CCF receives the 200 (OK) response for a standalone transaction request, the S-CCF shall: 

1) insert a P-Charging -Function- Addresses header populated with values received from the HSS if the message is 
forwarded within the S-CCF home network, including towards an AS; and 

2) if the response is not forwarded to an AS (i.e. the response is related to a request that was matched to the first 
executed initial filter criteria),insert a type 2 term-ioi parameter in the P-Charging-Vector header of the outgoing 
response. The type 2 term-ioi is set to a value that identifies the sending network of the response and the type 2 
orig-ioi parameter is set to the previously received value of orig-ioi. 

NOTE 1 l:If the S-CCF forked the request of a stand alone transaction to multiple UEs and receives multiple 200 
(OK) responses, the S-CCF will select and return only one 200 (OK) response. The criteria that the 
S-CCF employs when selecting the 200 (OK) response is based on the operator's poUcy (e.g. return the 
first 200 (OK) response that was received). 

When the S-CCF receives, destined for a served user, a target refresh request for a dialog, prior to forwarding the 
request, the S-CCF shall: 

OA) if the dialog is related to an IMS communication service determine whether the contents of the request (e.g. 
SDP media capabiUties, Content-Type header field) match the IMS communication service as received as the 
ICSI value in the P-Asserted-Service header in the initial request. As an operator option, if the contents of the 
request do not match the IMS communication service the S-CSCF may reject the request by generating a status 
code reflecting which added contents are not matching. Otherwise, continue with the rest of the steps; 

1) if the incoming request is received on a dialog for which GRUU routeing is to be performed and the 
Request-URI is not the GRUU for this dialog, then return a response of 400 (Bad Request). 

2) if the incoming request is received on a dialog for which GRUU routeing is to be performed and the 
Request-URI contains the GRUU for this dialog then the S-CCF shall: 

perform the procedures for Request Targeting specified in draft-ietf-sip-gruu [93], using the pubUc user 
identity and instance ID derived from the Request-URI, as specified in subclause 5.4.7A; 

- if no contact can be selected, return a response of 480 (Temporarily Unavailable). 

3) remove its own URI from the topmost Route header; 

4) for INVITE dialogs (i.e. dialogs initiated by an INVITE request), save the Contact and Cseq header field values 
received in the request such that the S-CCF is able to release the session if needed; 

5) create a Record-Route header containing its own SIP URI; and 

6) forward the request based on the topmost Route header. 

When the S-CCF receives any Ixx or 2xx response to the target refresh request for a dialog (whether the user is 
registered or not), the S-CCF shall: 

1) for INVITE dialogs, replace the saved Contact header field values in the response such that the S-CCF is able to 
release the session if needed; and 

2) in case the response is forwarded to an AS that is located within the trust domain, the S-CCF shall retain the 
P Access Network Info header and the access-network-charging-info parameter in the P-Charging- Vector 
header; otherwise, the S-CCF shall remove the P Access Network Info header and the access-network-charging- 
info parameter in the P-Charging-Vector header. 

When the S-CCF receives, destined for the served user, a subsequent request other than target refresh request for a 
dialog, prior to forwarding the request, the S-CCF shall: 
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1) if the incoming request is received on a dialog for which GRUU routeing is to be performed and the 
Request-URI is not the GRUU for this dialog, then return a response of 400 (Bad Request). 

2) if the incoming request is received on a dialog for which GRUU routeing is to be performed and the 
Request-URI contains the GRUU for this dialog then the S-CCF shall: 

- perform the procedures for Request Targeting specified in draft-ietf-sip-gruu [93], using the pubUc user 
identity and instance ID derived from the Request-URI, as specified in subclause 5.4.7A; 

- if no contact can be selected, return a response of 480 (Temporarily Unavailable). 

3) remove its own URI from the topmost Route header; and 

4) forward the request based on the topmost Route header. 

When the S-CCF receives a response to a subsequent request other than target refresh request for a dialog, in case the 
response is forwarded to an AS that is located within the trust domain, the S-CCF shall retain the P Access Network 
Info header and the access-network-charging-info parameter from the P-Charging- Vector header; otherwise, the S-CCF 
shall remove the access-network-charging-info parameter from the P-Charging-Vector header. 

With the exception of 305 (Use Proxy) responses, the S-CCF shall not recurse on 3xx responses. 
5.4.5.1 .2A Release of the existing dialogs due to registration expiration 

When the registration lifetime of the only public user identity currently registered with its associated set of implicitly 
registered public user identities (i.e. no other is registered) expires while there are still active multimedia sessions that 
includes this user 's contact address , where the session was initiated by or terminated towards the user with the contact 
address associated with the pubUc user identity currently registered or with one of the implicitly registered pubUc used 
identities, the S-CSCF shall release each of these multimedia sessions by applying the steps listed in the 
subclause 5.4.5.1.2. Only dialogs associated to the multimedia sessions originated or terminated towards the registered 
user's contact address shall be released. 

5.4.6.1.2 UE-originating case 

For a relNVITE request or UPDATE request from the UE within the same dialog, the S-CSCF shall store the updated 
access-network-charging-info parameter from P-Charging- Vector header in the received SIP request. The S-CSCF shall 
retain the access-network-charging-info parameter in the P-Charging- Vector header when the request is forwarded to an 
AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging- Vector 
header when the request is forwarded outside the home network of the S-CSCF. 

For a relNVITE request from the UE, if the request is to be forwarded to an AS that is located within the trust domain, 
the S-CSCF shall retain the P Access Network Info header and the access-network-charging-info parameter from the P- 
Charging- Vector header; otherwise, the S-CSCF shall remove the P Access Network Info header and the access- 
network-charging-info parameter from the P-Charging- Vector header. 

5.4.6.1.3 UE-terminating case 

For a relNVITE request or UPDATE request destined towards the UE within the same dialog, when the S-CSCF 
receives the 200 (OK) response (to the INVITE request or UPDATE request), the S-CSCF shall store the updated 
access-network-charging-info parameter from the P-Charging- Vector header. The S-CSCF shall retain the access- 
network-charging-info parameter in the P-Charging- Vector header when the response is forwarded to the AS. However, 
the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging- Vector header when the 
200 (OK) response is forwarded outside the home network of the S-CSCF. 

For any SIP response to an INVITE request, if the response is to be forwarded to an AS that is located within the trust 
domain, the S-CSCF shall retain the P Access Network Info header and the access-network-charging-info parameter 
from the P-Charging- Vector header; otherwise, the S-CSCF shall remove the P Access Network Info header and the 
access-network-charging-info parameter from the P-Charging- Vector header. 
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5.4.8.2 



Initial emergency registration or user-initiated emergency reregistration 



When the S-CSCF receives a REGISTER request without an "integrity protected" parameter, or with the "integrity- 
protected" parameter in the Authorization header set to "no" and the To header includes an emergency public user 
identity the S-CSCF shall perform the actions as specified in subclause 5.4.1.2.1 with the following additions: 

- if the emergency user identity is linked to a private user identity that has a registered emergency public user 
identity but with a new contact address, and the authentication has been successful and if the previous 
emergency registration has not expired, the S-CSCF shall delete the previous contact information. Contacts 
related to non-emergency registration shall not be deregislered. 

When the S-CSCF receives a REGISTER request with the "integrity-protected" parameter in the Authorization header 
set to "yes", the S-CSCF shall identify the user by the emergency public user identity as received in the To header and 
the private user identity as received in the Authorization header of the REGISTER request the S-CSCF shall perform 
the actions as specified in subclause 5.4.1.2.2 with the following additions: 

- the S-CSCF shall not include a Service-Route in the 200 (OK) to the REGISTER request; 

- the S-CSCF shall not include a temporary GRUU in the 200 (OK) to the REGISTER request; 

store the Path header and the contact information including all header parameters contained in the Contact 
header. The S-CSCF shall use the Path header and the contact information obtained during the emergency 
registration to build a preloaded Route header values for the emergency dialogs destined for the UE; 

NOTE 1: The Path header and contact information used for the emergency dialogs destined for the UE and obtained 

during the emergency registration can be different than the Path header used for the non-emergency 
communication and obtained during the non-emergency registration. 

NOTE 2: If the previous emergency registration with different contact information or emergency Path header has 
not expired, the S-CSCF will not perform the network initiated deregistration procedure for the previous 
emergency registration, but will let it expire. 

- the S-CSCF shall not send any third-party REGISTER requests to any AS; and 

- determine the duration of the registration by checking the value of the Expires header in the received REGISTER 
request and based on local poUcy. 

NOTE 3: The value of the emergency registration time is subject to national regulation and can be subject to 



It shall be possible for an AS based upon the service logic to vaUdate an ICSI value received in an Accept-Contact 
header or received in a P-Asserted-Service header and reject the request if necessary. 

A trusted AS may insert a P-Asserted-Service header field in a request for a new dialog or standalone transaction. An 
untrusted AS may insert a P-Preferred-Service header field in a request for a new dialog or standalone transaction. If the 
request is related to an IMS communication service that requires the use of an ICSI then the AS: 

- shall include the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service that 
is related to the request in either a P-Asserted-Service header field or a P-Preferred-Service header field 
depending whether the AS is trusted or not according to draft-drage-sipping-service-identification [121]. 

When an AS that is acting as a UA or initiating B2BUA or routeing B2BUA sends an initial request for a dialog or a 
request for a standalone transaction, the AS may include an Accept-Contact header field containing; 

: an ICSI value (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref feature tag as defined in 

subclause 7.9.2 and RFC 3841 r56B1; and 

- zereone or more lARI values (coded as specified in subclause 7.2A.9.2) that are related to the request in a 
g.ims.appiari-ref feature tag as defined in subcluase 7.9.23 and RFC 3841 [56B] 

if the ICSI or lARIs for the IMS communication service and IMS application are known. 



roaming agreements. 



5.7.1.9 



Use of ICSI and lARI values 



The AS may: 
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- include the received ICSI and lARI values; 

- replace or remove received ICSI and lARI values; or 

- include new ICSI and lARI values. 

When the AS acting as a UA or initiating B2BUA or routeing B2BUA sends a SIP request or a SIP response related to 
an IMS communication service, the AS may include in the Contact header field 

- in a g.3gpp.icsi-ref feature tag as defined in subclause 7.9.2 i n a g.ims.app ref feature tag zero one or more ICSI 
values (coded as specified in subclause 7.2A.8.2); and 

zereone or more lARl values (coded as specified in subclause 7.2A.9.2) in a g.3gpp.iari-ref feature tag , for the 
IMS applications communication service , that are related to the request as defined in subclause 7.9.2 and 
RFC 3840 [62]. 

if the ICSI or lARIs for the IMS communication service and IMS application are known. T he AS may: 

- include the received ICSI and lARI values; 
replace or remove received ICSI and lARI values; or 

- include new ICSI and lARI values. 

5.10.2.2 Initial requests 

Upon receipt of 

: an initialy request for a dialog; 

-- a request for a standalone transaction except the REGISTER method ; or 
- a request for an imknown method that does not relate to an existing dialog; 
, the IBCF shall: 

1) if the request is an INVITE request, respond with a 100 (Trying) provisional response; 

2) if the request is an INVITE request and the IBCF is configured to perform application level gateway and/or 
transport plane control functionalities, save the Contact, CSeq and Record-Route header field values received in 
the request such that the IBCF is able to release the session if needed; 

2A) if the request is an initial request for a dialog and local policv reqiures the application of IBCF capabilities in 
subsequent requests, perform record route procedures as specified in RFC 3261 [261; 

3) if network topology hiding is required, apply the procedures as described in subclause 5.10.4; 

4) if screening of SIP signalling is required, apply the procedures as described in subclause 5.10.6; 

5) if IBCF processes a request without a pre defined route (e.g. the subscription to reg event package originated by 
the P CSCF), select an entry point of the home network and forward the request to that entry point void ; 

NOTE 1: The list of the entry points can be either obtained as specified in RFC 3263 [27 A] or provisioned in the 
IBCF. The entry point can be an IBCF or an I CSCF. 

6) store the values from the P-Charging-Function-Addresses header, if present;-aHd 

7) remove some of the parameters from the P-Charging- Vector header or the header itself, depending on operator 
pohcy, if present; and 

8) remove the P-Charging-Function- Addresses headers, if present, prior to forwarding the message 

and forwards the request according to RFC 3261 [261. 

NOTE 1 : If IBCF processes a request wilhoul a pre-delined route (e.g. the subscriplion to reg event package 
originated by the P-CSCF), the next-hop address can be either obtained as specified in RFC 3263 [27 A1 or be 
provisioned in the IBCF. 
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When the IBCF receives an INVITE request, the IBCF may require the periodic refreshment of the session to avoid 
hung states in the IBCF. If the IBCF requires the session to be refreshed, it shall apply the procedures described in 
RFC 4028 [58] clause 8. 

NOTE 2: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

When the IBCF receives a response to the initial request and network topology hiding is required, then the IBCF shall 
apply the procedures as described in subclause 5.10.4. 

When the IBCF receives a response to the initial request and screening of SIP signalling is applied, then the IBCF shall 
apply the procedures as described in subclause 5.10.6. 

5.10.2.3 Subsequent requests 

Upon receipt of aay subsequent request , except the REGISTER method , the IBCF shall: 

1) if the request is an INVITE request, respond with a 100 (Trying) provisional response; 

2) if the request is a target refresh request and the IBCF is configured to perform application level gateway and/or 
transport plane control functionalities, save the Contact and CSeq header field values received in the request 
such that the IBCF is able to release the session if needed; 

3) if the subsequent request is other than a target refresh request (including requests relating to an existing dialog 
where the method is unknown) and the IBCF is configured to perform application level gateway and/or transport 
plane control functionalities, save the Contact and CSeq header field values received in the request such that the 
IBCF is able to release the session if needed; 

4) if network topology hiding is required, apply the procedures as described in subclause 5.10.4; and 

5) if screening of SIP signalling is required, apply the procedures as described in subclause 5.10.6v 

and forwards the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261 
[26L 

When the IBCF receives a response to the subsequent request and network topology hiding is required, then the IBCF 
shall apply the procedures as described in subclause 5.10.4. 

When the IBCF receives a response to the subsequent request and screening of SIP signalling is required, then the IBCF 
shall apply the procedures as described in subclause 5.10.6. 

5.10.3.2 Initial requests 

Upon receipt of 

- any initial request for a dialog ;T 

- a request for a standalone transaction except the REGISTER request; orT 

a request for an unknown method lhal does not relate to an existing dialog. 

the IBCF shall verify whether the request is arrived from a trusted domain or not. If the request arrived from an 
untrusted domain, then the IBCF shall; 

if the topmost Route header of the request contains the "orig" parameter, respond with 403 (Forbidden) 
response. Otherwise, 

remove all P Asserted Identity headers, all P Access Network Info headers, all P-Charging- Vector headers and 
all P-Charging-Function- Addresses headers the request may contain. 

Upon receipt of 

- any initial request for a dialog; T 

- a request for a standalone transaction except the REGISTER request;T or 
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- a request for an unknown method that does not relate to an existing dialog; 
the IBCF shall: 

1) if the request is an INVITE request, then respond with a 100 (Trying) provisional response; 

2) if the request is an INVITE request and the IBCF is configured to perform application level gateway and/or 
transport plane control functionalities, then the IBCF shall save the Contact, CSeq and Record-Route header 
field values received in the request such that the IBCF is able to release the session if needed; 

2A) if the request is an initial request for a dialog and local policy requires the application of IBCF capabilities in 
subsequent requests, perform record route procedures as specified in the RFC 3261 1261; 

3) if network topology hiding is required, then apply the procedures as described in subclause 5. 10.4; and 

4) If IBCF receives an initial request for a dialog or standalone transaction, that contains a single Route header 
pointing to itself, and it is co-located with an I-CSCF, or it has a preconfigured I-CSCF to be contacted, then 
forward the request to that I-CSCF. Otherwise select an I-CSCF and forward the request to that I-CSCF. If the 
single Route header of the request contains the "orig" parameter, the IBCF shall insert the "orig" parameter to the 
URI of the I-CSCF. 

NOTE 1: The selection of an I-CSCF can lead to additional delays. 

When the IBCF receives an INVITE request, the IBCF may require the periodic refreshment of the session to avoid 
hung states in the IBCF. If the IBCF requires the session to be refreshed, it shall apply the procedures described in 
RFC 4028 [58] clause 8. 

NOTE: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality 
cannot automatically be granted, i.e. at least one of the involved UEs needs to support it. 

When the IBCF receives a response to an initial request (e.g. 183 or 2xx), the IBCF shall: 

1) store the values from the P-Charging-Function- Addresses header, if present; 

2) remove the P-Charging-Function- Addresses header prior to forwarding the message; and 

3) if network topology hiding is required, then the IBCF shall apply the procedures as described in 
subclause 5.10.4. 

5.10.3.3 Subsequent requests 

Upon receipt of any subsequent request , except the REGISTER method , the IBCF shall: 

1) if the request is an INVITE request, then respond with a 100 (Trying) provisional response; 

2) if the request is a target refresh request and the IBCF is configured to perform apphcation level gateway and/or 
transport plane control functionalities, then the IBCF shall save the Contact and CSeq header field values 
received in the request such that the IBCF is able to release the session if needed; 

3) if the subsequent request is other than a target refresh request (including requests relating to an existing dialog 
where the method is unknown) and the IBCF is configured to perform application level gateway and/or transport 
plane control functionalities, then the IBCF shall save the Contact and CSeq header field values received in the 
request such that the IBCF is able to release the session if needed; and 

4) if network topology hiding is required, then apply the procedures as described in subclause 5.10.4v 

and forwards the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261 
[26L 

When the IBCF receives a response to the subsequent request and network topology hiding is required, then the IBCF 
shall apply the procedures as described in subclause 5.10.4. 
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5.10.6 Screening of SIP signalling 

5.10.6.1 General 

The IBCF may act as a B2BUA when it performs screening of SIP signalling functionality. In this case the B2BUA 
behaviour of the IBCF shall comply with the description given in subclause 5.10.5 for the IMS-ALG fiinctionaUty. 

NOTE: Many headers are intended for end-to-end operation; removal of such headers will impact the intended 
end-to-end operation between the end users. Additionally the IM CN subsystem does not preclude 
security mechanisms covering SIP headers; any such removal-ean may prevent validation of all headers 
covered by the security mechanism. Further studv in release 2 will be given to specifving procedures that 
can act in a more transparent manner to the end user for some of these screening functions, and therefore 
allow the screening function to use proxv behaviour. Use of draft-ietf-sipping-media-policy-dataset, draft- 
hilt-sipping-policv-package. draft-hilt-sipping-policv-usecases, draft-hilt-sipping-session-policv- 
framework, draft-hilt-sipping-session-spec -policy, and draft-camarillo-sipping-sbc-funcs will be 
investigated for this purpose. 

5.10.6.2 IBCF procedures for SIP headers 

If specified by local policy rules, the IBCF may omit or modify any other received SIP headers prior to forwarding SIP 
messages, with the following exceptions. 

As a result of any screening policy adopted, the IBCF should not modify at least the following headers which would 
cause mis-operation of the IM CN subsystem: 

Authorization; and 

- www-Authenticate. 

Where the IBCF appears in the path between the UE and the S-CCF, some headers are involved in the registration and 
authentication of the user. As a result of any screening policy adopted as part of normal operation, e.g. where the 
request or response is forwarded on, the IBCF should not modify as part of the registration procedure at least the 
following headers: 

- Path; and 

- Service-Route. 

NOTE 1: If the IBCF modifies SIP information elements (SIP headers, SIP message bodies) other than as specified 
by SIP procedures (e.g., RFC 3261 [26]) caution needs to be taken that SIP functionality (e.g., routeing 
using Route, Record-Route and Via) is not impacted in a way that could create interoperabiUty problems 
with networks that assume that this information is not modified. 

NOTE 2: Where operator requirements can be achieved by configuration hiding, then these procedures can be used 
in preference to screening. 

The IBCF may add, remove, or modify, the P-Early-Media header within forwarded SIP requests and responses 
according to procedures in draft-ejzak-sipping-p-em-auth [109]. 

NOTE 3: The IBCF can use the header for the gate control procedures, as described in 3GPP TS 29.214 [13D]. In 
the presence of early media for multiple dialogs due to forking, if the IBCF is able to identify the media 
associated with a dialog, (i.e., if symmetric RTP is used by the UE and the IBCF can use the remote SDP 
information to determine the source of the media) the IBCF can selectively open the gate corresponding 
to an authorized early media flow for the selected media. 

When the IBCF, located in the home network, receives a SIP request from another entity within the same trust domain, 
the IBCF may police the ICSI value contained in the P-Asserted-Service header field. 

5.10.6.3 IBCF procedures for SIP message bodies 

If IP address translation (N A(P)T or IP version interworking) occurs on the user plane, the IBCF shall modify SDP 
according to the corresponding annex F and G as appropriate. 

Additionally, the IBCF may take the foUowings action upon SIP message bodies: 
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1) examine the length of a SIP message body and if required by local policy, and take an appropriate action 
(e.g. forward the message body transparently, reject the request, remove the body); 

2) examine the characteristics of the message body (i.e. check the values of any "Content-Type", 
"Content-Disposition", and "Content-Language" headers), take an appropriate action defined by local policy (e.g. 
forward the body unchanged, remove the body, reject the call); and 

3) examine the content of SIP bodies, and take appropriate action defined by local policy (e.g. forward the body 
imchanged, remove the body, reject the call)._ 

5. 11 .2 UE originating case 

The E-CSCF may either forward the call to a PSAP in the IP network or forward the call to a PSAP in the PSTN. In the 
latter case the call will pass a BGCF and a MGCF before entering the PSTN. 

Upon receipt of an initial request for a dialog, or a standalone transaction, or an unknown method including a Request- 
URI with an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in draft-ietf- 
ecrit-service-urn [69], or an emergency number the E-CSCF shall: 

1) remove its own SIP URI from the topmost Route header; 

2) if the PSAP is the next hop, store the value of the icid parameter received in the P-Charging- Vector header and 
remove the received information in the P-Charging- Vector header, else keep the P-Charging- Vector if the next 
hop is an exit IBCF or a BGCF; 

3) if the PSAP is the next hop remove the P-Charging-Function- Addresses headers, if present, else keep the P- 
Charging-Function- Addresses headers if the next hop is an exit IBCFor an BGCF; 

4) if an IBCF or BGCF is the next hop insert a type 2 orig-ioi parameter into the P-Charging-Vector header. The E- 
CSCF shall set the type 2 orig-ioi parameter to a value that identifies the sending network. The E-CSCF shall not 
include the term-ioi parameter; 

5) get location information as 

- geographical location information received as a location object from a message body with the content type 
application/pidf+xml in accordance with draft-ietf-sip-location-conveyance [89]; and 

- location identifier as derived from the P- Access-Networ k Network Info header, if available. 

NOTE 1: The E-CSCF can request location information from an LRF. The protocol used to retrieve the location 
information from the LRF is not specified in this version of the specification. 

NOTE 2: As an alternative to retrieve location information from the LRF the E-CSCF can also request location 

information from an external server. The address to the external server can be received in the Geolocation 
header as specified in draft-ietf-sip-location-conveyance [89]. The protocol used to retrieve the location 
information from the external server is not specified in this version of the specification. 

6) select, based on location information and optionally type of emergency service: 

- a PSAP connected to the IM CN subsystem network and add the PSAP URI to the topmost Route header; or 

NOTE 3: The E-CSCF conveys the P-Access-Network-Info header containing the location identifier , if defined for 
the access type as specified in subclause 7.2A.4, to the PSAP. 

- a PSAP in the PSTN, add the BGCF URI to the topmost Route header and add a PSAP URI in tel URI format 
to the Request-URI with an entry used in the PSTN/CS domain to address the PSAP; 

NOTE 4: The E-CSCF conveys the P-Access-Network-Info header containing the location identifier , if defined for 
the access type as specified in subclause 7.2A.4, towards the MGCF. The MGCF can translate the 
location Information if included in INVITE (i.e. both the geographical location information in PIDF-LO 
and the location identifier in the P- Access-Network-Info header) into ISUP signalling, see 
3GPPTS 29.163 [IIB]. 
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NOTE 5: The E-CSCF can request location information and routeing information from the LRF. The E-CSCF can 
for example send the location identifier to LRF and LRF maps the location identifier into the 
corresponding geographical location information that LRF sends to E-CSCF. The LRF can invoke an 
RDF to convert the location information into a proper PSAP/EC URL Both the location information and 
the PSAP URI are returned to the E-CSCF. 

NOTE 6: The way the E-CSCF determines the next hop address when the PSAP address is a tel URI is 
implementation dependent. 

7) if the E-CSCF receives a reference number from the LRF the E-CSCF shall include the reference number in the 
P-Asserted-Identity header; 

NOTE 7: The reference number is used in the communication between the PSAP and LRF. 

8) if due to local policy or if the PSAP requires interconnect functionalities (e.g. PSAP address is of an IP address 
type other than the IP address type used in the IM CN subsystem), put the address of the IBCF to the topmost 
route header, in order to forward the request to the PSAP via an IBCF in the same network; 

9) create a Record-Route header containing its own SIP URI 

10) if the request is an INVITE request, save the Contact, Cseq and Record-Route header field values received in the 
request such that the E-CSCF is able to release the session if needed; and 

1 l)route the request based on SIP routeing procedures. 

Editor's Note: It needs to be investigated whether the E-CSCF also needs (under specific circumstances) to release 
an emergency session. 

NOTE 8: Depending on local operator policy, the E-CSCF has the capability to reject requests relating to specific 
methods in accordance with RFC 3261 [26], as an alternative to the functionality described above. 

Upon receipt of an initial request for a dialog, a standalone transaction, or an unknown method, that does not include a 
Request-URI with an emergency service URN or an emergency number, the E-CSCF shall reject the call by sending a 
403 (Forbidden) response. 

When the E-CSCF receives the request containing the access-network-charging-info parameter in the P-Charging- 
Vector, the E-CSCF shall store the access-network-charging-info parameter from the P-Charging- Vector header. The E- 
CSCF shall retain access-network-charging-info parameter in the P-Charging-Vector header. 

When the E-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) 
related to a UE -originated dialog or standalone transaction, the E-CSCF may insert previously saved values into P- 
Charging-Vector and P-Charging-Function-Addresses headers before forwarding the message. 

When the E-CSCF receives an INVITE request from the UE, the E-CSCF may require the periodic refreshment of the 
session to avoid hung states in the E-CSCF. If the E-CSCF requires the session to be refreshed, it shall apply the 
procedures described in RFC 4028 [58] clause 8. 

NOTE 9: Requesting the session to be refreshed requires support by at least the UE or the PSAP or MGCF. This 
functionality cannot automatically be granted, i.e. at least one of the involved UAs needs to support it in 
order to make it work. 

6 Application usage of SDP 

6.1.1 General 

The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the 
precondition mechanism" and is defined in RFC 3312 [30] as updated by RFC 4032 [64]. 

In order to authorize the media streams, the P-CSCF and S-CCF have to be able to inspect the SDP payloads. Hence, 
the UE shall not encrypt the SDP payloads. 

During session establishment procedure, SIP messages shall only contain SDP payload if that is intended to modify the 
session description, or when the SDP payload must be included in the message because of SIP rules described in 
RFC 3261 [26]. 
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For "video" and "audio" media types that utilize the RTP/RTCP, the UE shall specify the proposed bandwidth for each 
media stream utilizing the "b=" media descriptor and the "AS" bandwidth modifier in the SDP. 

If the media line in the SDP indicates the usage of RTP/RTCP, and if the RTCP bandwidth level for the session is 
different than the default RTCP bandwidth as specified in RFC 3556 [56], then in addition to the "AS" bandwidth 
modifier in the media-level "b=" line, the UE shall include two media-level "b=" lines, one with the "RS" bandwidth 
modifier and the other with the "RR" bandwidth modifier as described in RFC 3556 [56] to specify the required 
bandwidth allocation for RTCP. 

For other media streams the "b=" media descriptor may be included. The value or absence of the "b=" parameter will 
affect the assigned QoS which is defined in 3GPP 29.213 [13C]. 

NOTE 1: In a two-party session where both participants are active, the RTCP receiver reports are not sent, 
therefore, the RR bandwidth modifier will typically get the value of zero. 

The UE shall include the MIME subtype "telephone -event" in the "m=" media descriptor in the SDP for audio media 
flows that support both audio codec and DTMF payloads in RTP packets as described in RFC 2833 [23]. 

In case if the IP-CAN requires any access specific procedures, t he UE shall inspect the SDP contained in any SIP 
request or response, looking for possible indications of grouping of media streams according to RFC 3524 [54] and 
perform the appropriate actions for IP-CAN bearer establishment for media according to IP-CAN specific procedures 
(see subclause B.2.2.5 for IP-CAN implemented using GPRS). 

If resource reservation is needed, the UE shall start reserving its local resources whenever it has sufficient information 
about the media streams, media authorization and used codecs available. 

NOTE 2: Based on this resource reservation can, in certain cases, be initiated immediately after the sending or 
receiving of the initial SDP offer. 

In order to fulfil the QoS requirements of one or more media streams, the UE may re-use previously reserved resources. 
In this case the local preconditions related to the media stream, for which resources are re-used, shall be indicated as 

met. 

If an IP-CAN bearer is rejected or modified, the UE shall, if the SDP is affected, update the remote SIP entity according 
to RFC 3261 [26] and RFC 331 1 [29]. 

NOTE 3: The UE can use one IP address for signalling (and specify it in the Contact header) and different IP 
address(es) for media (and specify it in the "c=" parameter of the SDP). 

If the UE wants to transport media streams with TCP and there are no specific alternative negotiation mechanisms 
defined for that particular application, then the UE shall support the procedures and the SDP rules specified in 
RFC 4145 [83]. 

6.1 .2 Handling of SDP at the originating UE 

An INVITE request generated by a UE shall contain a SDP offer and at least one media description. The SDP offer 
shall reflect the calhng user's terminal capabihties and user preferences for the session. The UE shall order the SDP 
offer with the most preferred codec listed first. 

If the desired QoS resources for one or more media streams have not been reserved at the UE when constructing the 
SDP offer, the UE shall: 

- indicate the related local preconditions for QoS as not met, using the segmented status type, as defined in 
RFC 3312 [30] and RFC 4032 [64], as well as the strength-tag value "mandatory" for the local segment and the 
strength-tag value "optional" for the remote segment , if the UE supports the precondition mechanism (see 
subclause 5.1.3.1) ; and, 

- set the related media streams to inactive, by including an "a=inactive" line, according to the procedures 
described in RFC 4566 [39], unless the UE knows that the precondition mechanism is supported by the remote 
UE. 

NOTE 1: When setting the media streams to the inactive mode, the UE can include in the first SDP offer the proper 
values for the RS and RR modifiers and associate bandwidths to prevent the receiving of the RTCP 
packets, and not send any RTCP packets. 
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If the desired QoS resources for one or more media streams are available at the UE when the SDP offer is sent, the UE 
shall indicate the related local preconditions as met, using the segmented status type, as defined in RFC 3312 [30] and 
RFC 4032 [64], as well as the strength-tag value "mandatory" for the local segment and the strength-tag value 
"optional" for the remote segment, if the UE supports the precondition mechanism (see subclause 5.1.3.1). 

NOTE 2: If the originating UE does not support the precondition mechanism it will not include any precondition 
information in SDP. 

Upon generating the SDP offer for an INVITE request generated after receiving a 488 (Not Acceptable Here) response, 
as described in subclause 5.1.3.1, the UE shall include SDP payload containing a subset of the allowed media types, 
codecs and other parameters from the SDP payload of all 488 (Not Acceptable Here) responses related to the same 
session estabUshment attempt (i.e. a set of INVITE requests used for the same session estabUshment). The UE shall 
order the codecs in the SDP payload according to the order of the codecs in the SDP payload of the 488 (Not 
Acceptable Here) response. 

NOTE 3: The UE can attempt a session establishment through multiple networks with different policies and 

potentially can need to send multiple INVITE requests and receive multiple 488 (Not Acceptable Here) 
responses from different CSCF nodes. The UE therefore takes into account the SDP contents of aU the 
488 (Not Acceptable Here) responses received related to the same session establishment when building a 
new INVITE request. 

Upon confirming successful local resource reservation, the UE shall create a SDP offer in which: 

- the related local preconditions are set to met, using the segmented status type, as defined in RFC 3312 [30] and 

RFC 4032 [64]; and 

- the media streams previously set to inactive mode are set to active (sendrecv, sendonly or recvonly) mode. 

Upon receiving an SDP answer, which includes more than one codec for one or more media streams, the UE shall send 
an SDP offer at the first possible time, selecting only one codec per media stream. 

6.2 Procedures at the P-CSCF 

When the P-CSCF receives any SIP request containing an SDP offer, the P-CSCF shall examine the media parameters 
in the received SDP. If the P-CSCF finds any media parameters which are not allowed on the network by local poUcy, 
the P-CSCF shall return a 488 (Not Acceptable Here) response containing SDP payload. This SDP payload contains 
either all the media types, codecs and other SDP parameters which are allowed according to the local policy, or, based 
on configuration by the operator of the P-CSCF, a subset of these allowed parameters. This subset may depend on the 
content of the received SIP request. The P-CSCF shall build the SDP payload in the 488 (Not Acceptable Here) 
response in the same manner as a UAS builds the SDP in a 488 (Not Acceptable Here) response as specified in 
RFC 3261 [26]. The P-CSCF shall order the SDP payload with the most preferred codec listed first. If the SDP offer is 
encrypted, the P-CSCF may reject the request. 

When the P-CSCF receives a SIP response different from 200 (OK) response containing an SDP offer, the P-CSCF 
shall not examine the media parameters in the received SDP offer, but the P-CSCF shall rather check the succeeding 
request containing the SDP answer for this offer, and if necessary (i.e. the SDP answer reduced by the UE still breaches 
local policy), the P-CSCF shall return a 488 (Not Acceptable Here) response containing the local policy allowed SDP 
payload. If the SDP answer is encrypted, the P-CSCF may reject the succeeding request. 

When the P-CSCF receives a 200 (OK) response containing SDP offer, the P-CSCF shall examine the media parameters 
in the received SDP. If the P-CSCF finds any media parameters which are not allowed on the network by local poUcy, 
the P-CSCF shall forward the SDP offer and on the receipt of the ACK request containing the SDP answer, it shall 
immediately terminate the session as described in subclause 5.2.8.1.2. If the SDP offer is encrypted, the P-CSCF shall 
forward the SDP offer and on the receipt of the ACK request containing the SDP answer, it may immediately terminate 
the session as described in subclause 5.2.8.1.2. 

When the P-CSCF receives any SIP request containing an SDP offer for which resource authorization procedure over 
the Gq' interface is required (e.g. in case the P-CSCF is serving a UE connected to a fixed broadband access), upon 
receipt of an indication over the Gq' interface that the requested resources for a multimedia session currently being 
established cannot be granted (e.g. AA-Answer message from SPDF with appropriate reservation failure indication), the 
P-CSCF shall terminate this received request and answer it with a 500 (Server Internal Error) response. 

When the P-CSCF receives a 200 (OK) response containing an SDP offer, for which resource authorization procedure 
over the Gq' interface is required (e.g. in case the P-CSCF is serving a UE connected to a fixed broadband access), upon 
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receipt of an indication over the Gq' interface that the requested resources for a multimedia session currently being 
established cannot be granted (e.g. AA- Answer message from SPDF with appropriate reservation failure indication), the 
P-CSCF shall check the SIP message containing the SDP answer for this SDP offer, and if necessary (i.e. a new 
indication that resources cannot be granted is received by the P-CSCF over the Gq' interface), the P-CSCF shall 
terminate the session as described in subclause 5.2.8.1.2. 

In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)t-PT controlled 
by the P-CSCF, or by a hosted NAT , located along the media path, t he P-CSCF may need to modify the media 
connection data in SDP bodies according to the procedures described in F and/or annex G. 

The P-CSCF shall apply and maintain the same policy within the SDP from the initial request or response containing 
SDP and throughout the complete SIP session. The P-CSCF may inspect, if present, the "b=RS" and "b=RR" lines in 
order to find out the bandwidth allocation requirements for RTCP. 

7 Extensions within tlie present document 

7.2A.4 P-Access-Network-lnfo header 

7.2A.4.1 Introduction 

The P- Access-Network-Info header is extended to include specific information relating to particular access 
technologies. 

7.2A.4.2 Syntax 

The syntax of the P- Access-Network-Info header is described in RFC 3455 [52]. There are additional coding rules for 
this header depending on the type of IP-CAN, according to access technology specific descriptions. 

Table 7.6A describes 3GPP-specific extended syntax of the P-Access-Network-Info header field defined in 
RFC 3455 [52]. 

Table 7.6A: Syntax of extended P- Access-Network-Info header 

P-Access -Network- Inf o = ' P-Access-Network- Inf o ' HCOLON 

access-net-spec * (COMMA access-net-spec) 
access-net-spec = access-type — [SEMI np] * (SEMI access-info) 

access-type = ' IEEE-802 . 11 ' / "IEEE-802 . 11a" / "IEEE-802 . lib" / " IEEE-802 . llg" / 

"3GPP-GERAN" / "3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" / "ADSL" / "ADSL2 " / 
"ADSL2+" / "RADSL" / "SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" / "VDSL" / 
"IDSL" / "3GPP2-1X" / "3GPP2-1X-HRPD" / " IEEE- 802 . 3 " / " IEEE-802 . 3a" / 



"IEEE-802 ■3e" / " IEEE-802 . 3i " / "IEEE-802 . 3j " / " IEEE-802 . 3u" / "lEEE- 
802.3ab"/ " IEEE-802 . 3ae" /" IEEE- 802 . 3ak" /IEEE- 802 . 3aq" / " IEEE-802 . 3an" / 
"IEEE-802. 3y"/ "IEEE-802 . 3z"/ "IEEE-802 . 3y"/ token 

-Hp — "network ' provided" 

access-info = cgi-3gpp / utran-cell-id-3gpp / dsl-location / np / i-wlan-node-id / ci- 

3gpp2/ eth-location / extension- access-info 
extension-access-info = gen-value 

cgi-3gpp = "cgi-3gpp" EQUAL (token / quoted-string) 

utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL (token / quoted-string) 

i-wlan-node-id = "i-wlan-node-id" EQUAL (token / quoted-string) 

dsl-location = "dsl-location" EQUAL (token / quoted-string) 

eth- location = "eth-location" EQUAL (token / quoted-string) 

np = "network-provided" 

ci-3gpp2 = "ci-3gpp2" EQUAL (token / quoted-string) 



NOTE : Addition of the P- Access-Network-Info header by proxies, and repetition of the P- Access-Network-Info 
header within the same request or response, requires an update to RFC 3455 before such usage is valid. 

7.2A.4.3 Additional coding rules for P-Access-Network-lnfo header 

The UEE ntities inserting the P-Access-Network-Info header shall populate the P- Access-Network-Info header, where 
use is specified in subclause 5.1 and subclause 5.2, with the following contents: 
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1) the access-type field set to one of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", 
"3GPP2-1X", "3GPP2-1X-HRPD", "IEEE-802.1 1", "IEEE-802.11a", "IEEE-802.11b" "IEEE-802.1 Ig", 
"ADSL", "ADSL2", "ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL" , 
"DOCSIS" or "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-802.3i", "IEEE-802.3i", "IEEE-802.3u", 
"ffiEE-802.3ab", "IEEE-802.3ae", IEEE-802.3ak", IEEE-802.3aq", IEEE-802.3aii", "IEEE-802.3v", "lEEE- 
802.3z" or "IEEE-802.3v" as appropriate to the access technology in use. 

2) if the access type field is set to "3GPP-GERAN", a cgi-3gpp parameter set to the Cell Global Identity obtained 

from lower layers of the UE. The Cell Global Identity is a concatenation of MCC, MNC, LAC and CI (as 
described in 3GPP TS 23.003 [3]). The value of "cgi-3gpp" parameter is therefore coded as a text string as 
follows: 

Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC 
(fixed length code of 16 bits using full hexadecimal representation) and CI (fixed length code of 16 bits using 
a full hexadecimal representation); 

3) if the access type field is equal to "3GPP-UTRAN-FDD", or "3GPP-UTRAN-TDD", a "utran-cell-id-3gpp" 
parameter set to a concatenation of the MCC, MNC, LAC (as described in 3GPP TS 23.003 [3]) and the UMTS 
Cell Identity (as described in 3GPP TS 25.331 [9 A]), obtained from lower layers of the UE, and is coded as a 
text string as follows: 

Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC 
(fixed length code of 16 bits using full hexadecimal representation) and UMTS Cell Identity (fixed length 
code of 28 bits); 

4) if the access type field is set to "3GPP2-1X", a ci-3gpp2 parameter set to the ASCII representation of the 
hexadecimal value of the string obtained by the concatenation of SID (16 bits), NID (16 bits), PZID (8 bits) and 
BASEJD (16 bits) (see 3GPP2 C.S0005-D [85]) in the specified order. The length of the ci-3gpp2 parameter 
shall be 14 hexadecimal characters. The hexadecimal characters (A through F) shall be coded using the 
uppercase ASCII characters. If the MS does not know the values for any of the above parameters, the MS shall 
use the value of for that parameter. For example, if the SID is unknown, the MS shall represent the SID as 
0x0000; 

NOTE 1: The SID value is represented using 16 bits as supposed to 15 bits as specified in 3GPP2 C.S0005-D [85]. 

EXAMPLE: If SID = 0x1234, NID = 0x5678, PZID = 0x12, BASEJD = OxFFFF, the ci-3gpp2 value is set to 
the string "1234567812FFFF". 

5) if the access type field is set to "3GPP2-1X-HRPD", a ci-3gpp2 parameter set to the ASCII representation of the 
hexadecimal value of the string obtained by the concatenation of Sector ID (128 bits) and Subnet length 

(8 bits) (see 3GPP2 C.S0024-A [86]) in the specified order. The length of the ci-3gpp2 parameter shall be 34 
hexadecimal characters. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII 

characters; 

EXAMPLE: If the Sector ID = 0x12341234123412341234123412341234, Subnet length = 0x1 1, the ci-3gpp2 
value is set to the string "1234123412341234123412341234123411". 

6) if the access-type field set to one of "lEEE-802. 11", "IEEE-802.1 la", "lEEE-WLAN-802.1 lb" or 
"IEEE-802.1 Ig", an "i-wlan-node-id" parameter is set to the ASCII representation of the hexadecimal value of 
the AP's MAC address of the AP without any dehmiting characters . 

EXAMPLE: If the AP's MAC address = OO-OC-Fl-12-60-28, then i-wlan-node-id is set to the string 
"OOOcf 1126028". 

7) If the access-type field is set to one of "ADSL", "ADSL2", "ADSL2H-", "RADSL", "SDSL", "HDSL", "HDSL2", 
"G.SHDSL", "VDSL", "IDSL", the access-info field shall contain a dsl-location parameter obtained from the 
CLE (see NASS functional architecture) ; and 

8) if the access-type field set to "DOCSIS", the access info parameter is set to a null value. This release of this 
specification does not define values for use in this parameter. 

9) if the access-type field is set to one of "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e". "IEEE-802.3i", "lEEE- 
802.3i", "IEEE-802.3U", "lEEE-802.3ab", "IEEE-802.3ae", IEEE-802.3ak", IEEE-802.3aq", IEEE-802.3an", 
"IEEE-802.3v", "IEEE-802.3Z", "IEEE-802.3y", the access-info field shall contain an eth-location parameter 
obtained from the CLE (see NASS functional architecture). 
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NOTE 2: The "cgi-3gpp", the "utran-cell-id-3gpp", the "ci-3gpp2'\ the "i-wlan-node-id", and the "dsl-location" 
parameters described above among other usage also constitute the location identifiers that are used for 
IMS emergency services. 

If the P-CSCF receives an initial request for a dialog or standalone transaction or an unknown method and: 

- the request includes a P-Access-Network-Info header with a "network-provided" parameter the P-CSCF shall 
remove the P-Access-Network-Info header; 

- the request is sent using xDSL as an IP-CAN the P-CSCF may insert a P-Access-Network-Info header into the 
request by setting the access-type field to one of "ADSL", "ADSL2", "ADSL2+", "RADSL", "SDSL", "HDSL", 
"HDSL2", "G.SHDSL", "VDSL", or "IDSL", adding the "network-provided" parameter and the 
"dsl-location" parameter with the value received in the Location-Information header in the User-Data Answer 
command as specified in ETSI ES 283 035 [98]; and 

the request is sent using Ethernet as an IP-CAN the P-CSCF mav insert a P-Access-Network-Info header into the 
request bv setting the access-tvpe field to one of "IEEE-802.3". "IEEE-802.3a". "IEEE-802.3e". "IEEE-802.3i". 
"IEEE-802.3i", "IEEE-802.3U" ,"IEEE-802.3ab"or "IEEE-802.3ae", IEEE-802.3ak", IEEE-802.3aq", lEEE- 
802.3an", "IEEE-802.3v", "IEEE-802.3z" or "IEEE-802.3v", adding the "network-provided" parameter and the 
"eth-location" parameter with the value received in the Location-Information header in the User-Data Answer 
conmiand as specified in ETSI ES 283 035 [981; 

NOTE 3: The way the P-CSCF deduces that the request comes using xDSL access is implementation dependent. 

Editor's Note: Insertion of P- Access-Network-Info header by a P-CSCF is not allowed according to RFC 3455 [52] . 

- the request is sent using DOCSIS as an IP-CAN the P-CSCF may insert a P- Access-Network-Info header into 
the request by setting the access-type field to "DOCSIS" and including the "network-provided" parameter. 

NOTE 4: The way the P-CSCF deduces that the request comes using DOCSIS access is implementation dependent. 

Editor's Note: Insertion of P- Access-Network-Info header by a P-CSCF is not allowed according to RFC 3455 [52]. 

7.2A.5.2.2 GPRS as IP-CAN 

GPRS is the initially supported access network (gprs-charging-info parameter). For GPRS there are the following 
components to track: GGSN address (ggsn parameter), media authorization token (auth token parameter), and a pdp- 
info parameter that contains the information for one or more PDP contexts. In this release the media authorization token 
is set to zero. The pdp-info contains one or more pdp-item values followed by a collection of parameters (pdp-sig, gcid, 
and flow-id). The value of the pdp-item is a unique number that identifies each of the PDP-related charging information 
within the P-Charging- Vector header. Each PDP context has an indicator if it is an IM CN subsystem signalling PDP 
context (pdp-sig parameter), an associated GPRS Charging Identifier (gcid parameter), and a identifier (flow-id 
parameter). The flow-id parameter contains a sequence of curly bracket delimited flow identifier tuples that identify 
associated m-lines and relative order of port numbers in an m-line within the SDP from the SIP signalling to which the 
PDP context charging information apphes. For a complete description of the semantics of the flow-id parameter see 
3GPP TS 29.214 [13D] Annex B. The gcid, ggsn address and flow-id parameters are transferred from the GGSN to the 
P-CSCF via the PCRF over the Rx interface (see 3GPP TS 29.214 [13D] and Gx interface (see 3GPP TS 29.212 [13B]). 

The gcid value is received in binary format at the P-CSCF (see 3GPP TS 29.214 [13D]). The P-CSCF shall encode it in 
hexadecimal format before include it into the gcid parameter. On receipt of this header, a node receiving a gcid shall 

decode from hexadecimal into binary format. 

The access network charging information is not included in the P-Charging- Vector for SIP signalling that is not 
associated with a multimedia session. The access network charging information may not be unavailable for sessions that 
use a general purpose PDP context (for both SIP signalling and media) or that do not require media authorisation. 

7.2A.8.2 Coding of the ICSI 

This parameter is coded as a URN. The ICSI URN may be included asi 

- a tag value quoted string as a value of within the g.3gpp.icsi-ref g.ims.app ref media feature tag as defined in 
subclause 7.9.2 and RFC 3840 [62] shall be represented in the escaped encoding as defined in RFC 3986 [124]; 
or 
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- as a value of the P-Preferred-Service or P-Asserted-Service-Service header fields as defined draft-drage-sipping- 

service-identification [121]. 

A list of the URNs containing ICSI values registered by 3GPP can be found at 
http://www.3gpp.org/tb/Other/URN/URN.htm 

An example of an ICSI for a 3GPP defined IMS communication service is: 

urn : urn- 7 : 3 gpp- service . ims . icsi . mmtel urn : urn xxx : tel e phony . 3gpp . mmt c l 

An example of a g.3gpp.icsi-re f g.ims.app ref media feature tag containing an ICSI for a 3GPP defined IMS 
communication service is: 

g • 3gpp ■ icsi-re£ = "urn%3Aurn- 7 %3A3gpp- service ■ ims .icsi .mmtel " g ■ imp . app - ro£ - " <urn lurn - 
xxx! telephony . 3gpp ■mmtol> " 

An example of an ICSI for a 3GPP defined IMS conmiunication service in a P-Preferred-Service header field is 

P-Pref erred-Service : urn : urn- 7 : 3gpp- service ■ ims .icsi .mmtel urn !urn - xxx! telephony . 3gpp .mmtel 

An example of an ICSI for a 3GPP defined IMS communication service in a P-Asserted-Service header field is 

P-Asserted-Service : urn : urn- 7 : 3gpp- service . ims .icsi .mmtel urn !urn - xxx; t e l e phony . 3gpp .mmt e l 

7.2A.9.2 Coding of the lARI 

This parameter is coded as a URN. The lARI URN may be included as a quoted string as a value of the g.ims.appiari- 
ref media feature tag as defined in subclause 7.9.2 and RFC 3840 [621 , in which case those characters of the URN that 
are not part of the tag-value definition in RFC 3840 [621 shall be represented in the escaped encoding as defined in 

RFC 3986 [1241 . 

A list of the URNs containing lARI values registered by 3GPP can be found at 
http://www.3gpp.org/tb/Other/URN/URN.htm 

An example of a g.3gpp.iari-re f g.ims.app ref media feature tag containing an lARI is: 

g. 3gpp . iari-ref = "urn%3Aurn- 7 %3A3gpp- application. ims . iari .mmtel-application-vl" g. im p . gpp - ref 

= "<urn !urn - xxx; t e l e phony . 3gpp .mmt e l . application - vl>" 



7.2A.1 0.3 Additional coding rules for phone-context parameter 

In case the current IP-CAN is indicated in the phone -context the entities inserting the "phone-context" parameter shall 
populate the "phone-context" parameter with the following contents: 

1) if the IP-CAN is GPRS, then the "phone-context" parameter is a domain name. It is constructed from the MCC, 
the MNC and the home network domain name by concatenating the MCC, MNC, and the string "gprs" as 
domain labels before the home network domain name; 

EXAMPLE: If MCC = 216, MNC = 01, then the "phone-context" parameter is set to '216.01.gprs.homel.net'. 

2) if the IP-CAN is I-WLAN, then the "phone-context" parameter is a domain name. It is constructed from the 
SSID, AP's MAC address, and the home network domain name by concatenating the SSID, AP's MAC address, 
and the string "i-wlan" as domain labels before the home network domain name; 

EXAMPLE: If SSID = BU-Airport, AP's MAC = OO-OC-Fl-12-60-28, and home network domain name is 

"homel.net", then the "phone-context" parameter is set to the string "bu-airport.000cfll26028.i- 
wlan.homel .net" . 

3) if the IP-CAN is xDSL, then the "phone-context" parameter is a domain name. It is constructed from the dsl- 
location (see subclause 7.2A.4) and the home network domain name by concatenating the dsl-location and the 
string "xdsl" as domain labels before the home network domain name; 

4) if the IP-CAN is DOCSIS, then the "phone-context" parameter is based on data configured locally in the UE; and 
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4a) if the IP-CAN is Ethernet, then the "phone -context" parameter is a domain name. It is constructed from the 
eth-location (see subclause 7.2A.4) and the home network domain name by concatenating the eth-location and 
the string "ethernet" as domain labels before the home network domain name; and 

5) if the access network information is not available in the UE, then the "phone-context" parameter is set to the 
home network domain name preceded by the string "geo-local". 

In case the home domain is indicated in the phone-context, the "phone-context" parameter is set to the home network 
domain name (as it is used to address the SIP REGISTER request, see subclause 5.1.1.1A). 

In case the "phone -context" parameter indicates a network other than the home network or the visited access network, 
the "phone-context" parameter is set according to RFC 3966 [22]. 

7.6.1 General 

This subclause contains the 3GPP IM CN Subsystem XML body in XML format. The 3GPP IM CN Subsystem XML 
shall be valid against the 3GPP IM CN Subsystem XML schema defined in table 1.1 A. 

Any SIP User Agent or proxy may insert or remove the 3GPP IM CN subsystem XML body or parts of it, as required, 
in any SIP message. The 3GPP IM CN subsystem XML body shall not be forwarded outside a 3GPP network. 

The associated MIME type with the 3GPP IMS XML body is "appUcation/3gpp-ims-Hxnil". 

7.6.2 Document Type Definition 

The XML Schema is defined in table 1.1 A. 



Table 7.7 A: IM CN subsystem XML body, XML Schema 



<?xml version="l . 0" encoding= "UTF- 8 " ? > 




<xs : schema xmlns :xs= "http : //www. w3 . org/2 OOl/XMLSchema" element FormDefault= "qualified" 




attributeFormDef ault= "unqualified" version= " 1 " > 
<xs : complexType name= " tIMSSGPP" > 




<xs : sequence > 




<xs : choice> 




<xs : element name= "alternative- service" type= " tAlternativeService" /> 




<xs:element name="service-info" type="xs : string"/> 




</xs : choice> 




<xs:any namespace="##any" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" 


/> 


</xs : sequence> 




<xs : attribute name= "version" type= "xs : decimal " use="required"/> 
<xs :anyAttribute/> 




</xs : complexType> 




<xs : complexType name= "tAlternativeService" > 




<xs : sequence> 




<xs: element name="type" type="tType"/> 




<XD!Olomont name- "action" — typo- "tAct ion" minOccuro- " " / > 




<xs;element name="reason" type= "xs : string" /> 




<xs:element name= "action" type=" tAct ion" minOccurs="0"/> 

<xs:any namespace="##any" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" 


/> 


</xs : sequence> 




</xs : complexType> 




<xs : complexType name="tType"> 




<xs : sequence> 




<xs; element name= "emergency" minOccurs= " " maxOccurs= " 1 " > 




<xs : complexType/> 




</xs : element> 




<xs:any namespace="##any" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" 


/> 


</xs : sequence> 




<xs : anyAttribute/ > 




</xs : complexType> 




<xs : complexType name=" tAct ion "> 




<xs : sequence> 




<xs: element name= "emergency-registration" minOccurs= " " maxOccurs= " 1 " > 




<xs : complexType/ > 




</xs : element> 




<xs:any namespace="##any" processContents= " lax" minOccurs= " " maxOccurs= "unbounded" 


/> 


</xs : sequence> 




<xs :anyAttribute/> 




</xs : complexType> 




<xs:element name="ims-3gpp" type="tIMS3GPP"/> 
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</xs : schema> 



7.6.3 XML Schema description 

This subclause describes the elements of the IMS Document Type Definition as defined in table 7.7A. 

<ims-3gpp>: This is the root element of the IMS XML body. It shall always be present. XML instance 

documents of future versions of the XML Schema in table 7. 7 A shall be valid against the XML 
Schema in table 7.7A in this document. XML instance documents of the XML Schema in 
table 7.7A in the present document shall have a version attribute value, part of the ims-3gpp 
element, that is equal to the value of the XML Schema version described in the present document. 

<service-info>: the transparent element received from the HSS for a particular trigger point are placed within this 
optional element. 

<alternative-service>: in the present document, the alternative service is used as a response for an attempt to 

establish an emergency session within the IM CN subsystem. The element describes an alternative 
service where the call should success. The alternative service is described by the type of service 
information. A possible reason cause why an alternative service is suggested may be included. 

The <alternative-service> element contains a <type> element that indicates the type of alternative 
service and an <action> element, an optional element. 

The <type> element contains only the value "emergency" in the present document. 

The <action> element contains only the value "emergency-registration" in the present document. 

The <reason> element contains an explanatory text with the reason why the session setup has been 
redirected. A UE may use this information to give an indication to the user. 

7.9.2 Definition of media feature tag g.ims.appiari-ref 

Media feature-tag name: g.ims.app re f g.3gpp.icsi-ref 

ASN. 1 Identifier: New assignment by IAN A. 

Editor" s note: The media feature -tag name is to be registered with IAN A. 

Summary of the media feature indicated by this tag: Each value of the Service Application reference Media feature-tag 
indicates the software applications supported by the agent. The values for this tag equal the IMS communication 
Service Identifier (ICSI) and IMS Application Reference Identifier (lARI) values supported by the agent. 

The Service Application Reference media feature tag Media Feature Tag is defined to fulfil the requirements for forking 
to an appropriate UE when multiple UEs are registered and dispatch to an appropriate application within the UE based 
upon the IMS communication Service Identifier (ICSI) and IMS Application Reference Identifier (lARI) values as 
stated in 3GPP TS 23.228 [7]. 

Multiple tag-values can be included in the Application Reference media feature-tag. 
Values appropriate for use with this feature-tag: Token, with an equality relationship. 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: 

This feature-tag is most useful in a communications application, for describing the capabilities of a device, such 
as a phone or PDA. 

Examples of typical use: Routeing an IMS Communication Session to a device that supports a particular software 
application or understands a particular service. 

Related standards or documents: 

3GPP TS 24.229: "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session 
Description Protocol (SDP), stage 3" 
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Security Considerations: Security considerations for this media feature-tag are discussed in subclause 11.1 of 
RFC 3840 [6]. 

7.9.3 Definition of media feature tag g.3gpp.iari-ref 

Media feature-tag name: g.3gpp.iari-ref. 

ASN. 1 Identifier: New assignment by IAN A. 

Editor" s note: The media feature -tag name is to be registered with IAN A. 

Summary of the media feature indicated by this tag: Each value of the Application Reference media feature-tag 
indicates the software applications supported by the agent. The values for this tag equal IMS Application Reference 
Identifier (lARI) values supported by the agent 

The Application Reference media feature tag is defined to fulfil the requirements for forking to an appropriate UE when 
multiple UEs are registered and dispatch to an appropriate application within the UE based upon and IMS Application 
Reference Identifier (lARI) values as stated in 3GPP TS 23.228 U]. 

Multiple tag-values can be included in the Application Reference media feature-tag. 

Values appropriate for use with this feature-tag: Token with an equality relationship. 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: 

This feature-tag is most useful in a communications application, for describing the capabilities of a device, such 
as a phone or PDA. 

Examples of typical use: Routeing an IMS Application Session to a device that supports a particular software 
application or understands a particular application. 

Related standards or documents: 

3GPP TS 24.229: "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session 
Description Protocol (SDP), stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 11.1 of 
RFC 3840 [61. 

Annex A Profiles of IETF RFCs for 3GPP ETSI TISPAN usage 

A. 2. 1.2 Major capabilities 

Editor's note: it needs to be checked whether it should be explicitly clarified that the IBCF (IMS-ALG) is 
transparent to some presence or conference extensions. 
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[28] 


c2 
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23 
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[28] 


c2 


c16 


24 
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contacts? 


[35] 





c6 


25 
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Initiation Protocol (SIP) for networl< 
asserted identity within trusted 
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[34] 





m 


26 


a privacy mechanism for the Session 
Initiation Protocol (SIP)? 
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m 
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request of privacy by the inclusion of a 
Privacy header indicating any privacy 
option? 
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received Privacy header? 
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c9 


n/a 
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26D 
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Item 


Does the implementation support 


Reference 


RFC status 


Profile status 


26F 


application of the privacy option "user" 
sucli tliat user level privacy functions are 
provided by the network? 


[33] 5.3 


clO 


c27 


26G 


application of the privacy option "id" 
such that privacy of the network 
asserted identity is provided by the 
network? 


[34] 7 


clO 


n/a 


26H 


application of the privacy option "history" 
such that privacy of the History-Info 
header is provided by the network? 


[66] 7.2 


c37 


c37 


27 


a messaging mechanism for the Session 

Initiation Protocol (SIP)? 


[50] 





c7 


28 


session initiation protocol extension 
header field for service route discovery 
during registration? 


[38] 





c17 


29 


compressing the session initiation 
protocol? 


[55] 





c8 


30 


private header extensions to the session 
initiation protocol for the 3rd-Generation 
Partnership Project (3GPP)? 


[52] 





m 


31 


the P-Associated-URI header extension? 


[52] 4.1 


c21 


c22 


32 


the P-Called-Party-ID header extension? 


[52] 4.2 


c21 


c23 


33 


the P-Visited-Network-ID header 

extension? 


[52] 4.3 


c21 


c24 


34 


the P-Access-Network-lnfo header 
extension? 


[52] 4.4 


c21 


c25 


35 


the P-Charging-Function-Addresses 
header extension? 


[52] 4.5 


c21 


c26 


36 


the P-Charging-Vector header 
extension? 


[52] 4.6 


c21 


c26 


37 


security mechanism agreement for the 
session initiation protocol? 


[48] 





c20 


38 


the Reason header field for the session 
initiation protocol? 


[34A] 







39 


an extension to the session initiation 
protocol for symmetric response 
routeing? 


[56A] 





xo 


40 


caller preferences for the session 
initiation protocol? 


[56B] 


C29 


c29 


40A 


the proxy-directive within caller- 
preferences? 


[56B] 9.1 


0.5 


0.5 


40B 


the cancel-directive within caller- 
preferences? 


[56B] 9.1 


0.5 


0.5 


40C 


the fork-directive within caller- 
preferences? 


[568] 9.1 


0.5 


c28 


40D 


the recurse-directive within caller- 
preferences? 


[56B] 9.1 


0.5 


0.5 


40 E 


the parallel-directive within caller- 
preferences? 


[56B] 9.1 


0.5 


c28 


40F 


the queue-directive within caller- 
preferences? 


[56B] 9.1 


0.5 


0.5 


41 


an event state publication extension to 
the session initiation protocol? 


[70] 





c30 


42 


SIP session timer? 


[58] 


c19 


c19 


43 


the SIP Referred-By mechanism? 


[59] 





c33 


44 


the Session Initiation Protocol (SIP) 
"Replaces" header? 


[60] 


c19 


c38 (note 1 ) 


4b 


the Session Initiation Protocol (SIP) 
"Join" header? 


[61] 


CI y 


CI y (note i ) 


46 


the caller capabilities? 


[62] 





c35 


47 


an extension to the session initiation 
protocol for request history information? 


[66] 








48 


Rejecting anonymous requests in the 
Session Initiation Protocol (SIP) 


[67] 
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Item 


Does the implementation support 


Reference 


RFC status 


Profile status 


49 


session initiation protocol URIs for 
applications such as voicemail and 
interactive voice response 


[68] 








50 


Session Initiation Protocol s (SIP) non- 
INVITE transactions? 


[84] 


ID 


ID 


51 


the P-User-Database private header 
extension? 


[82] 4 





©c94 


52 


a uniform resource name for services 


[69] 


n/a 


c39 


53 


obtaining and using GRUUs in the 
Session Initiation Protocol (SIP) 


[93] 





c40 (note 2) 


54 


an extension to the session initiation 

protocol for request cpc information? 


[95] 


(note 3) 


c41 


55 


the Stream Control Transmission 
Protocol (SCTP) as a Transport for the 
Session Initiation Protocol (SIP)? 


[96] 





c42 


56 


the SIP P-Profle-Key private header 

extension? 


[97] 


n/a 


n/a 


57 


managing client initiated connections in 
SIP? 


[92] 





c45 


58 


indicating support for interactive 
connectivity establishment in SIP? 


[102] 





c46 


59 


multiple-recipient MESSAGE requests in 
the session initiation protocol? 


[104] 


c47 


c48 


60 


SIP location conveyance 


[89] 





c49 


61 


referring to multiple resources in the 
session initiation protocol? 


[105] 


c50 


c50 


62 


conference establishment using request- 
contained lists in the session initiation 
protocol? 


[106] 


c51 


c52 


63 


subscriptions to request-contained 
resource lists in the session initiation 
protocol? 


[107] 


c53 


c53 


64 


dialstring parameter for the session 
initiation protocol uniform resource 

identifier? 


[103] 





c19 


65 


the P-Answer-State header extension to 
the session initiation protocol for the 
open mobile alliance push to talk over 
cellular? 


[111] 





c60 


66 


the SIP P-Early-Media private header 
extension for authorization of early 
media? 


[109] 8 





c58 


71 


addressing an amplification vulnerability 
in session initiation protocol forking 
proxies? 


[117] 


n/a 


n/a 


Z2 


the remote application identification of 
applying signalling compression to SIP 


[79] 9.1 





c8 


Z3 


a session initiation protocol media 
feature tag for IVIIME application sub- 
types? 


[120] 





c59 


74 


Identification of communication services 
in the session initiation protocol? 


[121] 





c61 


75 


XIVIL Schema for PSTN? 


[ANNEX ZBl 


m 


c62 


c2: IF A.4/20 THEN o.1 ELSE n/a - - SIP specific event notification extension. 




c3: IF A.3/1 OR A.3/4 THEN m ELSE n/a - - UE or S-CCF functional entity. 






c4: IF A.3/4 THEN m ELSE IF A.3/7 THEN o ELSE n/a - - S-CCF or AS functional entity. 




c5: IF A.4/16 THEN m ELSE o - - Integration of resource management and SIP extension. 
c6: IF A.3/4 OR A.3/1 THEN m ELSE n/a. - - S-CCF or UE. 




c7: IF A.3/1 OR A.3/4 OR A.3/7A OR A.3/7B OR A.3/7D OR A.3/9B THEN m ELSE n/a - - UA or S-CCF or AS 


acting as terminating UA or AS acting as originating UA or AS performing 3'^'' party call control or IBCF 
(IMS-ALG). 

C8: IF A.3/1 THEN (IF (A.3B/1 OR A.3B/2 OR A.3B/3 OR A.3B/4 OR A.3B/5 OR A.3B/11 OR A.3B/12 OR 
A.3B/13 OR A.3B/14) THEN m ELSE o) ELSE n/a - - UE behaviour (based on P-Access-Network-lnfo 


usage). 

c9: IF A. 4/26 THEN 0.2 ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c10: IF A.4/26B THEN 0.3 ELSE n/a - - application of privacy based on the received Privacy header. 
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Item I Does the implementation support | Reference | RFC status | Profile status 

c1 1 : IF A.3/1 OR A.3/6 THEN o ELSE IF A.3/9B THEN m ELSE n/a - - UE or MGCP, IBCF(IMS-ALG). 
c12: IF A.3/7D THEN m ELSE n/a - - AS performing 3rd-party call control. 

c13: IF A.3/1 OR A.3/2 OR A.3/4 OR A.3/9B THEN m ELSE o - - UE or S-CCF or IBCF (IMS-ALG). 

C14: IF A.3/1 AND A4/2B (A.3B/1 OR A.3B/2 OR A.3B/3 OR A.3B/4 OR A.3B/5) THEN m ELSE I F A.3/2 THEN o 

ELSE _n/a - UE with appropriate access technoloqv and i n i t i at i ng s e ssions or P - CSCF . 
c1 5: IF A.4720 AND (A.3/4 OR A.3/9B) THEN m ELSE o - SIP specific event notification extensions and S-CCF 

or IBCF ( IMS-ALG). 

c16: IF A.4/20 AND (A.3/1 OR A.3/2 OR A.3/9B) THEN m ELSE o - - SIP specific event notification extension and 

UE or P-CSCF or IBCF (IMS-ALG). 
c1 7: IF A.3/1 or A.3/4 THEN m ELSE n/a - - UE or S-CCF 
c1 8: IF A.4/2B THEN m ELSE n/a - - initiating sessions. 
c1 9: IF A.4/2B THEN o ELSE n/a - - initiating sessions. 
c20: IF A.3/1 THEN m ELSE n/a - - UE behaviour. 

c21 : IF A.4/30 THEN 0.4 ELSE n/a - - private header extensions to the session initiation protocol for the 
3rd-Generatlon Partnership Project (3GPP). 

c22: IF A.4/30 AND (A.3/1 OR A.3/4) THEN m ELSE n/a - - private header extensions to the session initiation 
protocol for the 3rd-Generation Partnership Project (3GPP) and S-CCF or UA. 

c23: IF A.4/30 AND A.3/1 THEN o ELSE n/a - - private header extensions to the session initiation protocol for the 
3rd-Generation Partnership Project (3GPP) and UE. 

c24: IF A.4/30 AND A.3/4) THEN m ELSE n/a - - private header extensions to the session initiation protocol for 
the 3rd-Generation Partnership Project (3GPP) and S-CCF. 

c25: IF A.4/30 AND ( A.3/1 OR A.3/4 OR A.3/7A OR A.3/7D OR A.3/9B) THEN m ELSE IF A.4/30 AND A.3/1 
AND (A.3B/1 OR A.3B/2 OR A.3B/3 OR A.3B/4 OR A.3B/5 OR A.3B/1 1 OR A.3B/12 OR A.3B/13 OR 
A.3B/14 OR A.3B/41) THEN m ELSE IF A.4/30 AND A.3/1 AND (A.3B/210R A.3B/22 OR A.3B/23 OR 
A.3B/24 OR A.3B/25 OR A.3B/26 OR A.3A/27 OR A.3A/28 OR A.3B/29 OR A.3B/30) THEN o ELSE n/a - - 
private header extensions to the session initiation protocol for the 3rd-Generatlon Partnership Project 
(3GPP)i and UE, S-CCF or AS acting as terminating UA or AS acting as third-party call controller or 
IBCF (IMS-ALG) , UE, P-Access-Network-lnfo values . 

c26: IF A.4/30 AND (A.3/6 OR A.3/7A OR A.3/7B or A.3/7D) THEN m ELSE n/a - - private header extensions to 
the session initiation protocol for the 3rd-Generatlon Partnership Project (3GPP) and MGCF, AS acting as a 
terminating UA, or AS acting as an originating UA, or AS acting as third-party call controller. 

c27: IF A.3/7D THEN o ELSE x - - AS performing 3rd party call control. 

c28: IFA.3/1 THEN m ELSE 0.5- -UE. 

c29: IF A.4/40A OR A.4/40B OR A.4/40C OR A.4/40D OR A.4/40E OR A.4/40F THEN m ELSE n/a - - support of 

any directives within caller preferences for the session initiation protocol. 
c30: IF A.3A/1 OR A.3A/2 THEN m ELSE IF A.3/1 THEN o ELSE n/a - - presence server, presence user agent, 

UE, AS. 

c33: IF A.3/9B OR A.3 A /1 1 OR A.3 A /1 2 OR A.4/44 THEN m ELSE o - - BCF (IMS-ALG) or conference focus or 

conference participant or the Session Initiation Protocol (SIP) "Replaces" header. 
c34: IF A.4/44 OR A.4/45 OR A.3/9B THEN m ELSE n/a - - the Session Initiation Protocol (SIP) "Replaces" 

header or the Session Initiation Protocol (SIP) "Join" header or IBCF (IMS-ALG). 
C35: IF A.3/4 OR A.3/9 B OR A.3A/21 OR A.3A/22 THEN m ELSE IF (A.3/1 OR A.3/6 OR A.3/7 OR A.3/8) THEN 

ELSE n/a - - S-CCF or BCF (IMS-ALG)_functlonal entities or CSI user agent or CSI application server, UE 

or MGCF or AS or MRFC functional entity. 
c37 IF A.4/47 THEN 0.3 ELSE n/a - - an extension to the session initiation protocol for request history 

information. 

c38: IF A.4/2B AND (A.3A/1 1 or A.3A/12 or A.3/7D) THEN m ELSE IF A.4/2BTHEN o ELSE n/a -- initiating 

sessions, conference focus, conference participant, AS performing 3rd party call control. 
c39: IF A.3/1 THEN m ELSE n/a- - UE. 

c40 IF A.3/4 OR A.3/1 THEN m ELSE IF (A.3/7A OR A.3/7B OR A.3/7D) THEN o ELSE n/a - - S-CCF, UE, AS, 

AS acting as terminating UA, or redirect server, AS acting as originating UA, AS performing 3rd party call 
control. 

c41 : IF A.3/2 OR A.3/3 OR A.3/4 OR A.3.5 OR A.3/6 OR A.3/7 OR A.3/8 OR A.3/9 THEN o ELSE n/a - - cpc URI 

parameter. 
c42: IFA.3/1 n/a ELSE o -- UE. 
c43: IF A.4/2B THEN o ELSE n/a - - Initiating sessions. 

c44: IF A.4/2C THEN m ELSE o - - initiating a session which require local and/or remote resource reservation. 

c45: IF A.3/1 OR A.3/2 OR A.3/4 THEN o ELSE n/a - - UE, S-CCF functional entity. 

c46 IF A.3/1 OR A.3/2 OR A.3/4 THEN o ELSE n/a - - UE, S-CCF functional entity. 

c47: IF A.4/27 THEN o ELSE n/a - - a messaging mechanism for the Session Initiation Protocol (SIP). 

c48: IF A.3A/32 AND A.4/27 THEN m ELSE IF A.4/27 THEN o ELSE n/a - - messaging list server, a messaging 

mechanism for the Session Initiation Protocol (SIP). 
c49: IF A.3/1 OR A.3/9B THEN m ELSE o - - UE, IBCF (IMS-ALG). 
c50: IF A.4/1 5 THEN o ELSE n/a - - the REFER method. 
c51 : IF A.4/2B THEN o ELSE n/a - - initiating a session. 

c52: IF A.3A/1 1 AND A.4/2B THEN m ELSE IF A.4/2B THEN o ELSE n/a - - conference focus, initiating a 
session. 
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Item I Does the implementation support | Reference | RFC status | Profile status 

c53: IF A.4/20 THEN o ELSE n/a - - SIP specific event notification. 
c58: IF A.3/9B OR A.3/6 THEN m ELSE o - - IBCF (IMS-ALG), MGCF. 

c59: IF (A.3/4 THEN m ELSE IF (A.3/1 OR A.3/6 OR A.3/7A OR A.3/7B OR A.3/7D OR A.3/8) THEN o ELSE n/a 
- - S-CCF, UE, MGCF, AS, AS acting as terminating UA, or redirect server, AS acting as originating UA, AS 
performing 3rd party call control, or IVIRFC. 

c60: IF A.3/9B THEN m ELSE IF A.3/1 OR A.3/7A OR A.3/7B OR A.3/7D THEN o ELSE n/a - - IBCF (IMS-ALG), 
UE, AS acting as terminating UA, AS acting as originating UA, AS performing 3'^" party call control. 

c61 : IF (A.3/1 OR A.3/6 OR A.3/7A OR A.3/7B OR A.3/7D OR A.3/8 OR A.3/9B) THEN o ELSE n/a - - UE, MGCF, 

AS, AS acting as terminating UA, or redirect server, AS acting as originating UA, AS performing 3rd party call control, 

or MRFC or IBCF (IMS-ALG). 

c62: IF A.3/6 OR A.3/7A OR A.3/7B OR A.3/7D THEN o ELSE IF A.3/9B THEN o ELSE n/a - - MGCF. AS acting 
as terminating UA, or redirect server. AS acting as originating UA. AS performing 3rd party call control. 
IBCF (IMS-ALG). 

c94: IF A.3/4 OR A.3/7A OR A.3/7D THEN o ELSE n/a - - S-CSCF and AS acting as terminating UA or redirect 

server or AS performing 3rd party call control. 
0.1 : At least one of these capabilities is supported. 
0.2: At least one of these capabilities is supported. 
0.3: At least one of these capabilities is supported. 
0.4: At least one of these capabilities is supported. 

0.5: At least one of these capabilities is supported. 

NOTE 1 : At the MGCF, the interworl<ing specifications do not support a handling of the header associated with this 
extension. 

NOTE 2: If a UE is unable to become engaged in a service that potentially requires the ability to identify and interact 
with a specific UE even when multiple UEs share the same single Public User Identity then the UE support 
can be "o" instead of "m". Examples include telemetry applications, where point-to-point communication is 
desired between two users. 

NOTE 3: It has to be clarified within the draft that the cpc value belongs to the trust domain and shall not be populated 
by UE"s. 
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Prerequisite A.5/20 - - SIP specific event notification 



Table A.4A: Supported event packages 



Item 


Does the implementation 
support 


Subscriber 


Notifier 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


reg event package? 


[43] 


c1 


c3 


[43] 


c2 


c4 


1A 


reg event package extension 
for GRUUs? 


[94] 


Cl 


c25 


[94] 


c2 


c4 


2 


refer package? 


[36] 3 


c13 


c13 


[36] 3 


c13 


c13 


3 


presence package? 


[7416 


cl 


c5 


[7416 


c2 


c6 


4 


event list witti underlying 
presence package? 


[75], [74] 6 


cl 


c7 


[75], [74] 6 


c2 


c8 


5 


presence.winfo template- 
package? 


[72] 4 


cl 


c9 


[72] 4 


c2 


clO 


6 


ua-profile package? 


[77] 3 


cl 


c11 


[77] 3 


c2 


c12 


7 


conference package? 


[7813 


cl 


c21 


[7813 


cl 


c22 


8 


message-summary package? 


[65] 


cl 


c23 


[65] 3 


c2 


c24 


9 


poc-settings package 


[110] 


cl 


c26 


[110] 


c2 


c27 



AS. 



presence server, acting as the notifier of event 
watcher, acting as the subscriber to event 
resource list server, acting as the notifier of event 
presence user agent, acting as the subscriber to 
presence server, acting as the notifier of event 



cl : IF A.4/23 THEN o ELSE n/a - - acting as the subscriber to event information. 

c2: IF A.4/22 THEN o ELSE n/a - - acting as the notifier of event information. 
c3: IF A.3/1 OR A.3/2 THEN m ELSE IF A.3/7 THEN o ELSE n/a - - UE, P-CSCF, 

c4: IF A.3/4 THEN m ELSE n/a-- S-CCF. 

c5: IF A.3A/3 OR A.3A/4 THEN m ELSE IF A.4/23 THEN o ELSE n/a - - resource list server or watcher, acting 

as the subscriber to event information. 
c6: IF A.3A/1 THEN m ELSE IF A.4/22 THEN o ELSE n/a ■ 

information. 

c7: IF A.3A/4 THEN m ELSE IF A.4/23 THEN o ELSE n/a ■ 

information. 

c8: IF A.3A/3 THEN m ELSE IF A.4/22 THEN o ELSE n/a ■ 

information. 

c9: IF A.3A/2 THEN m ELSE IF A.4/23 THEN o ELSE n/a ■ 

event information, 
cl 0: IF A.3A/1 THEN m ELSE IF A.4/22 THEN o ELSE n/a ■ 

information. 

cl 1 : IF A.3A/2 OR A.3A/4 THEN o ELSE IF A.4/23 THEN o ELSE n/a - - presence user agent or watcher, acting 

as the subscriber to event information, 
cl 2: IF A.3A/1 OR A.3A/3 THEN m ELSE IF A.4/22 THEN o ELSE n/a - - presence server or resource list server, 

acting as the notifier of event information. 
c13: IF A.4/15 THEN m ELSE n/a - - the REFER method. 

c21 : IF A.3A/1 2 THEN m ELSE IF A.4/23 THEN o ELSE n/a - - conference participant or acting as the subscriber 
to event information. 

c22: IF A.3A/1 1 THEN m ELSE IF A.4/22 THEN o ELSE n/a - - conference focus or acting as the notifier of event 
information. 

c23: IF (A.3/1 OR A.3/7A OR A.3/7B) AND A.4/23 THEN o ELSE n/a - - UE, AS acting as terminating UA, or 

redirect server, AS acting as originating UA all as subscriber of event information. 
c24: IF (A.3/1 OR A.3/7A OR A.3/7B) AND A.4/22 THEN o ELSE n/a - - UE, AS acting as terminating UA, or 

redirect server, AS acting as originating UA all as notifier of event information. 
c25: IF A.4A/1 THEN (IF A.3/1 AND A.4/53 THEN m ELSE o) ELSE n/a - - reg event package, UE, reg event 

package extension for GRUUs. 
c26: IF (A.3/7B OR A.3/1 ) AND (A.4/23 OR A.4/41 ) THEN o ELSE n/a - - AS acting as originating UA, UE ,acting 

as the subscriber to event information, an event state publication extension to the session initiation protocol. 
c27: IF (A.4/22 OR A.4/41) AND A.3/1 THEN o ELSE n/a - - UE, acting as the notifier of event information, an 
event state publication extension to the session initiation protocol. 
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A.2. 1.4.7 INVITE method 

Prerequisite A.5/8 - - INVITE request 



Table A.46: Supported headers within the INVITE request 



Item 


Header 


Sending 


Receiving 


KGT. 


Status 


Profile 
status 


KeT. 


stdtus 


Profile 
status 




A * 

Accept 


[^Dj d\J.\ 








roci on 1 


FTl 


m 


i A 


Accept-Contact 


rccDi Q o 

[ODDj ij.d 


C^4 


C<;4 


rccDi Q o 
[ODDj \d.d 


Co^ 


CO<i 


o 
d. 


Accept- Encoding 


roci OA o 
[d.o\ dU.d. 








roci OA o 


FTl 


m 


o 


Accept-Language 


roci OA o 
[iibj iiU.o 








rO£^l OA o 

[^bj d.\).6 


FTl 


m 


4 


Aiert-inTo 


rod OA A 








roci OA A 

[db\ dUA 


Cl 


Cl 


c 


Allow 


roci on 
rofil R 1 


^noie 1 ) 





roci on 


FTl 


m 


o 
D 


MllUvv-CvclUb 


roQi 7 o o 


Cd. 


C^ 


rofti 7 o 

[^OJ 1 .d.d 


Cd 


c^ 


o 



A 1 l + k»("\l'|-7'a+l/M'l 

MULi lUilZaLIUll 


roci on 7 


Co 


Co 


roci on 7 


Co 


Co 


Q 

y 


Poll in 


roci OA D 


m 


m 


roci on Q 


FTl 


m 


1 u 


Pall Infn 
Oall-lnTO 


roftl on Q 








roci on Q 








i i 
1 1 


Pf^ntQ^t 


FORI on 1 n 


m 


m 


roci on 1 n 


FTl 


m 


1 


OUlUclU uibpubiiiuii 


roRi OA -1 -1 
\dXy\ dXj. \ \ 








roci on 1 1 


FTl 


m 


1 o 




roci OA 1 o 








roci OA 1 o 


m 


m 




f^^^ + ^K^t 1 ^"^ J 1 O 

LfOnieni-Language 


rOCl OA "1 Q 
[^Dj d\j.\o 








roci on i o 


FTl 


m 


1 


oonienT-Lengin 


rofil on 14 

[^DJ d\j. \ H- 


Fn 


m 


FORI on A A 


FT! 


m 


1 D 


L/L)lUcllL 1 ypt? 


roci on 1 c: 


FTl 


m 


FOCI on -1 c: 


FTl 


m 


1 / 


CSGQ 


roci on 1 c 


m 


m 


roci on i c 


FTl 


m 


1 




roCl OA i 7 


C4 


r^A 

C4 


roci OA i 7 


FTl 


m 


"1 Q 


expires 


rOCl OA "1 Q 








roci on i Q 








on 


From 


[26] 20.20 


FTl 


m 


[26] 20.20 


FTl 


m 


20A 


Geolocation 


roQi o o 


Coo 


Coo 


FQQl O O 

[oyj O.d 


Coo 


Coo 


one 


History-Info 


[DDj 4.1 


Col 


Col 


reel /I i 
[bbj 4.1 


Col 


Col 


ill 


In-Reply-To 


rod OA OH 








roci OA OH 
\dX>\ d\J.d\ 








O-l A 
dA A 


Join 


[61] 7.1 


CoU 


CoU 


rCH 1 "7 H 

[61] 7.1 


CoU 


CoU 


oo 


Max-Forwards 


roci on oo 


FTl 


m 


roci on oo 
[^oj dxj.dd 


Fi/a 


n/a 


OQ 


iviiivit- version 


roci on Ovi 








roci on o/i 


FTl 


m 


A 


iviin-ot 


rcQi c 

[ooj 


Cdo 


CiLo 


[OoJ 


C^O 


Cti.0 


OA 


Organization 


roci on oc 

[^ibj dxj.do 








roci on oc 
[^bj dXJ.dO 








0>1 A 

^4A 


P-Access- Network- 1 nf o 


rcoi A A 
[Od\ 4.4 


nH C 
Cl 


Cl O 


rcoi A A 
\pd\ 4.4 


r>H C 
Cl 


cl / 


^4d 


P-Asserted-ldentlty 


[o4j y.i 


n/a 


n/a 


ro^i Q H 

[o4j y.1 


C/ 


Cl 




P-Asserted-Service 


[1 J 4.1 


n/a 


n/a 


\^o^^ A h 
[1 ^1 J 4.1 


Coo 


Coo 


OA n 


r-uaiiea-rariy-iu 


rcol A O 
[O^J 4.^ 


X 


x 


rcoi A o 
[Od\ ^.d 


Cl o 


ClO 


^4t 


P-Cliarging-Function- 
Aaaresses 


\pd.\ 4.0 


nOA 


CdA 


rcoi A c 
[O^iJ 4.0 


j^OA 


CiJI 


^4r 


r-L/narging- vecTOi 




r1 ft 


O 1 ^ 


rcoi A ft 


r1 ft 


1 ^ 


9/1 


r -cdriy-iviyuid. 


r-1 nQi Q 
[ 1 uyj o 


Co4 


C04 


[ 1 uyj o 


Co4 


C04 


£-0 


r -jVicUld AULiIUriZaLIUi 1 


[O 1 J O.I 


n/a 


n/a 


rQi 1 1 

[o 1 J 0.1 


C 1 1 


C 1 ^1 


£_OA 


r - i icIuriuU lUcI uiiy 


ro/ii Q o 

[o4J 


^7 

c/ 


Co 


rOyll A O 

[o4J )3.d 


n/a 


n/a 




r -"reTerrea-oervice 


FH Oi 1 ^ O 

[1 d.\ J 4.^1 


Co/ 


Cod 


ri Oi 1 ^ o 
[1 ^1 J 4.^1 


n/a 


n/a 




roTiie-r\cy 


rQ71 ^^ 


Fi/a 


n/a 


FQ71 R 

[y/j 


n/a 


n/a 




r Ubci-L/dldUdbu 




n/a 


n/a 


fftOl A 
\pd\ 4 


n/a 


n/a 


0^^ 
d.OC 


P \/icitoH Mo+vA/nrU' IH 
r V IblluU INcLVvUIrN, ILJ 


[OiiJ 4.0 


X (noie o) 


x 


rc^oi A Q 
[O^J 4.0 


C 1 4 


n/a 


£-D 


r riui iiy 


FORI on Ofi 








roci on OR 










1 1 1 vduy 


[33] 4.2 


c9 


c9 


[33] 4.2 


c9 


c9 


27 


Proxy-Autliorization 


[26] 20.28 


c6 


c6 


[26] 20.28 


n/a 


n/a 


28 


Proxy-Require 


[26] 20.29 


(note 2) 


(note 2) 


[26] 20.29 


n/a 


n/a 


28A 


Reason 


[34A] 2 


c8 


c8 


[34A] 2 


c8 


c8 


29 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


m 


m 


30 


Referred-By 


[59] 3 


c27 


c27 


[59] 3 


c28 


c28 


31 


Reject-Contact 


[568] 9.2 


c24 


c24 


[56B] 9.2 


c32 


c32 


31A 


Replaces 


[60] 6.1 


c29 


c29 


[60] 6.1 


c29 


c29 


31B 


Reply-To 


[26] 20.31 








[26] 20.31 








31B 


Request-Disposition 


[56B] 9.1 


c24 


c24 


[56B] 9.1 


c32 


c32 


32 


Require 


[26] 20.32 





m 


[26] 20.32 


m 


m 


33 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


33A 


Security-Client 


[48] 2.3.1 


c22 


c22 


[48] 2.3.1 


n/a 


n/a 
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Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Receiving 



Ref. 



RFC 
status 



Profile 
status 



33B 



Security-Verify 



[48] 2.3.1 



c23 



c23 



[48] 2.3.1 



n/a 



n/a 



33C 



Session-Expires 



[58] 4 



c25 



c25 



[58] 4 



c25 



c25 



34 



Subject 



[26] 20.36 



[26] 20.36 



35 
36 
37 



Supported 



[26] 20.37 



m 



m 



[26] 20.37 



m 



m 



Timestamp 



[26] 20.38 



c10 



clO 



[26] 20.38 



m 



m 



To 



[26] 20.39 



m 



m 



[26] 20.39 



m 



m 



38 

39 
c1: 
c2: 
c3: 
c4: 
c5: 

c6: 
c7: 

c8: 

c9: 

clO 

c11 

c12 

c13 

c14 

c15 

CIS 

c17 



User-Agent 



[26] 20.41 



[26] 20.41 



Via 



[26] 20.42 



m 



m 



[26] 20.42 



m 



m 



c36: 

c37: 
c38: 
0.1: 



IF A. 4/1 2 THEN m ELSE n/a - - downloading of alerting information. 

IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A.3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol (SIP) 
for asserted identity within trusted networks. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted identity 
within trusted networks. 
IF A.4/38 THEN o ELSE n/a - 
IF A.4/26 THEN o ELSE n/a - 
IF A.4/6 THEN o ELSE n/a - - 
IFA.4/19THEN m ELSE n/a ■ 
IF A.3/1 THEN m ELSE n/a - 
IF A.4/32 THEN o ELSE n/a - 
IF A.4/33 THEN o ELSE n/a - 
IF A.4/34 THEN o ELSE n/a - 



- the Reason header field for the session initiation protocol. 

- a privacy mechanism for the Session Initiation Protocol (SIP), 
timestamping of requests. 

- SIP extensions for media authorization. 

UE. 

- the P-Called-Party-ID extension. 

- the P-Visited-Network-ID extension. 

- the P-Access-Network-lnfo header extension. 
IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 
AS acting as terminating UA or AS acting as third-party call controller. 

ELSE n/a - - the P-Charging-Vector header extension, 
m ELSE n/a - - the P-Charging-Vector header extension. 
ELSE n/a - - the P-Charging-Function-Addresses header extension, 
m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
ELSE n/a - - security mechanism agreement for the session initiation protocol (note 4). 
m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
ELSE n/a - - caller preferences for the session initiation protocol, 
m ELSE n/a - - the SIP session timer. 
ELSE n/a - - the SIP session timer, 
m ELSE n/a - - the SIP Referred-By mechanism. 
ELSE n/a - - the SIP Referred-By mechanism, 
m ELSE n/a - - the Session Initiation Protocol (SIP) "Replaces" header, 
m ELSE n/a - - the Session Initiation Protocol (SIP) "Join" header. 

m ELSE n/a - - an extension to the session initiation protocol for request history information, 
m ELSE n/a - - caller preferences for the session initiation protocol, 
m ELSE n/a - - SIP location conveyance. 

m ELSE n/a - - The SIP P-Early-Media private header extension for authorization of early 
media. 

IF A.3/1 AND A.4/74 THEN o ELSE n/a - - UE and identification of communication services in the session 
initiation protocol. 

IF A.4/74 THEN o ELSE n/a - - Identification of communication services in the session initiation protocol. 
IF A.4/74 THEN m ELSE n/a - - Identification of communication services in the session initiation protocol. 
At least one of these shall be supported. 



c18 


IF 


A 


4/36 


THEN 


c19 


IF 


A 


4/36 


THEN 


c20 


IF 


A 


4/35 


THEN 


c21 


IF 


A 


4/35 


THEN 


c22 


IF 


A 


4/37 


THEN 


c23 


IF 


A 


4/37 


THEN 


c24 


IF 


A 


4/40 


THEN 


c25 


IF 


A 


4/42 


THEN 


c26 


IF 


A 


4/42 


THEN 


c27 


IF 


A 


4/43 


THEN 


c28 


IF 


A 


4/43 


THEN 


c29 


IF 


A 


4/44 


THEN 


c30 


IF 


A 


4/45 


THEN 


c31 


IF 


A 


4/47 


THEN 


c32 


IF 


A 


4/40 


THEN 


c33 


IF 


A 


4/60 


THEN 


c34 


IF 


A 


4/66 


THEN 



NOTE 1 : 
NOTE 2: 



NOTE 3: 
NOTE 4: 



RFC 3261 [26] gives the status of this header as SHOULD rather than OPTIONAL. 

No distinction has been made in these tables between first use of a request on a From/To/Call-ID 

combination, and the usage in a subsequent one. Therefore the use of "o" etc. above has been included 

from a viewpoint of first usage. 

The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT. 
Support of this header in this method is dependent on the security mechanism and the security architecture 
which is implemented. Use of this header in this method is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 
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Table A.47: Void 

Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 



Table A.48: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 



ETSI 



Release 7 



121 



ETSI TS 124 503 V8.6.0 (2009-09) 



Prerequisite A.5/9 - - INVITE response for all remaining status-codes 

Table A.49: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


c12 


c12 


[26] 20.5 


m 


m 


1 


« 1 1 1 nv 


[26J 20.8 


m 


m 


[26J 20.8 


m 


m 


1 A 


Oall-lnfo 


[26] 20.9 








[26] 20.9 








2 


Content-Disposition 


[26] 20.1 1 








[26] 20.1 1 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.1 3 








[26] 20.13 


m 


m 


5 


Content-Lengtfn 


[26] 20.14 


m 


m 


[26J 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


c1 


c1 


[26] 20.17 


m 


m 


8- 


Expires 


[26] 20.19 








[26] 20.19 








9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


Geolocation 


[89] 3.2 


c14 


c14 


[89] 3.2 


c14 


c14 


9B 


History-Info 


[66] 4.1 


c13 


c13 


[66] 4.1 


c13 


c13 


10 


IVIIIVIE-Version 


[26] 20.24 








[26] 20.24 


m 


m 


1 1 


Organization 


[26] 20.25 








[26] 20.25 








-1 -1 A 

1 1 A 


P-Access-Network-lnfo 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


1 1 B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


11C 


P-Cliarging-Functlon- 
Addresses 


[52] 4.5 


clO 


c11 


[52] 4.5 


c11 


c11 


HHP* 

1 1 u 


P-Cliarging-Vector 


[52] 4.D 


C8 


C9 


[52] 4.6 


C8 


C9 


lib 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


11F 


Privacy 


[33] 4.2 


c4 


c4 


[33] 4.2 


c4 


c4 


11G 


Reply-To 


[26] 20.31 








[26] 20.31 








11H 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


111 


Server 


[26] 20.35 








[26] 20.35 








11J 


Reason 


Annex ZB 




c15 


Annex ZB 




c15 


12 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 








[26] 20.41 








14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


(note) 





[26] 20.43 









c1: 

c2: 
c3: 

c4: 
c5: 
c6: 
c7: 

c8: 

c9: 

c10 

c11 

c12 

c13 

c14 

c15 



IFA.4/11 THEN ELSE n/a - 
IF A.4/6 THEN m ELSE n/a - 
IF A.4/25 THEN o ELSE n/a - 
witliin trusted networl<s. 
IF A.4/26 THEN o ELSE n/a - 
IF A.4/34 THEN o ELSE n/a - 



- insertion of date in requests and responses. 

timestamping of requests. 

- private extensions to the Session Initiation Protocol (SIP) for asserted identity 



a privacy mechanism for the Session Initiation Protocol (SIP), 
the P-Access-Network-lnfo header extension. 
IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 
AS acting as terminating UA or AS acting as third-party call controller. 
IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
IF A.6/6 OR A.6/18 THEN m ELSE o - - 200 (OK), 405 (Method Not Allowed). 

IF A.4/47 THEN m ELSE n/a - - an extension to the session initiation protocol for request history information. 
IF A.4/60 THEN m ELSE n/a - - SIP location conveyance. 

IF A. 4/38 THEN o ELSE n/a - - the Reason header field for the session initiation protocol. 



NOTE: For a 488 (Not Acceptable Here) response, RFC 3261 [26] gives the status of this header as SHOULD 
rather than OPTIONAL. 
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Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/101A - - Additional for 18x response 

Table A.50: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Contact 


[26] 20.10 





m 


[26] 20.10 


m 


m 


5 


P-Answer-State 


M111 


c13 


c13 


M111 


c13 


c13 


5A 


P-Early-Media 


[109] 8 


c14 


c14 


[109] 8 


c14 


c14 


6 


P-Media-Authorization 


[31] 5.1 


n/a 


n/a 


[31] 5.1 


c11 


c12 


9 


Rseq 


[27] 7.1 


c2 


m 


[27] 7.1 


c3 


m 



c2: 
c3: 
c11 

c12 
c13 

c14: 



IF A.4/14 THEN ELSE n/a - 
IFA.4/14THEN m ELSE n/a - 
IFA.4/19THEN m ELSE n/a - 
IF A.3/1 THEN m ELSE n/a - - 
IF A.4/65 THEN m ELSE n/a - 
the open mobile alliance push 
IF A.4/66 THEN m ELSE n/a - 
media. 



- reliability of provisional responses in SIP. 

- reliability of provisional responses in SIP. 

- SIP extensions for media authorization. 

UE. 

- the P-Answer-State header extension to the session initiation protocol for 
to talk over cellular. 

- the SIP P-Early-Media private header extension for authorization of early 



Prerequisite A.5/9 - - INVITE response 
Prerequisite: A.6/102 - - Additional for 2xx response 

Table A.51 : Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


1A 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


1B 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


2 


Allow-Events 


[28] 7.2.2 


c3 


c3 


[28] 7.2.2 


c4 


c4 


4 


Authentication-Info 


[26] 20.6 


Cl 


cl 


[26] 20.6 


c2 


c2 


6 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


7 


P-Answer-State 


[111] 


c14 


c14 


[111] 


c14 


c14 


8 


P-Media-Authorization 


[31] 5.1 


n/a 


n/a 


[31] 5.1 


c11 


c12 


9 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


m 


m 


10 


Session-Expires 


[58] 4 


c13 


c13 


[58] 4 


c13 


c13 


13 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



cl: 
c2: 
c3: 
c4: 
c11 
c12 
c13 
c14 



IF A.4/7 THEN ELSE n/a - 
IF A.4/7THEN m ELSE n/a - - 
IF A.4/20 THEN o ELSE n/a - 
IF A.4/20 THEN m ELSE n/a - 
IFA.4/19THEN m ELSE n/a - 
IF A.3/1 THEN m ELSE n/a - - 
IF A.4/42 THEN m ELSE n/a - 
IF A.4/65 THEN m ELSE n/a - 
the open mobile alliance push 



authentication between UA and UA. 
authentication between UA and UA. 

- SIP specific event notification extension. 

- SIP specific event notification extension. 

- SIP extensions for media authorization. 
UE. 

- the SIP session timer. 

- the P-Answer-State header extension to the session initiation protocol for 
to talk over cellular. 
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Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 



Table A.51 A: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/103 OR A.6/35 - - Additional for 3xx or 485 (Ambiguous) response 



Table A.52: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Contact 


[26] 20.10 


(note 1 ) 





[26] 20.10 


m 


m 


NOTE: The strength of this requirement is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/14 - - Additional for 401 (Unauthorized) response 



Table A.53: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Proxy-Authenticate 


[26] 20.27 


c3 


c3 


[26] 20.27 


c3 


c3 


13 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/50 OR A.6/51 - - Additional for 404 (Not Found), 413 
(Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal Server Error), 600 (Busy 
Everywhere), 603 (Dechne) response 



Table A.54: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


8 


Retry-After 


[26] 20.33 








[26] 20.33 
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Table A.55: Void 

Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.56: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Proxy-Authenticate 


[26] 20.27 


Cl 


Cl 


[26] 20.27 


cl 


cl 


11 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1 : IF A. 4/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.57: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


0.1 


At least one of these capabilities is supported. 













Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/27 - - Additional for 420 (Bad Extension) response 

Table A.58: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


10 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Reqiured), 494 (Security Agreement Required) 
response 

Table A.58A: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


c1 


cl 


c1 : IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
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Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/28A - - Additional for 422 (Session Interval Too Small) response 



Table A.58B: Supported headers within the INVITE response 



Item 


Header 




Sending 


Receiving 








Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Min-SE 


[58] 5 


c1 


c1 


[58] 5 


c1 


c1 


c1: 


IF A.4/42 THEN o ELSE n/a - 


- the SIP session timer. 











Table A.59: Void 
Table A.60: Void 

Prerequisite A.5/9 - - INVITE response 
Prerequisite: A.6/45 - - 503 (Service Unavailable) 



Table A.61 : Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


8 


Retry-After 


[28] 20.33 








[26] 20.33 





m 



Prerequisite A.5/9 - - INVITE response 

Table A.62: Supported message bodies within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.12 REGISTER method 

Prerequisite A.5/18 - - REGISTER request 



Table A.119: Supported headers within the REGISTER request 



Item 


Header 


Sending 


Receiving 


HGT. 


Status 


Profile 
status 


KeT. 


Status 


Profile 
status 


i 
1 


A * 

Accept 


foci on 1 








roci on i 


m 


m 


o 

d. 


Accept-Encocling 


roci on o 








roci OA o 


m 


m 


Q 
O 


Accept-Language 


roci OA o 








roci OA o 


m 


m 




Allow 










roci OA c 


m 


nri 


4 


Allow-Events 


rooi "7 o o 






rooi 7 o o 


Cl 


cl 


c 


Authorization 


roci on 7 
[4yj 


C<i 




roci on 7 

r^Ql 
[4yj 


m 


Cd.d. 


o 
D 


Pall in 


roci on Q 


m 


m 


roci OA J3 


m 


m 


7 


Pall Infn 


roci on Q 








roci OA Q 








Q 


ooniaci 


roci on i A 





m 


roci OA i A 


m 


m 


Q 


oonLenT-uisposiuon 


rofti on 1 1 








rod OA H "i 


m 


m 


1 n 

1 u 


OUI llui IL CI luUUli ly 


rofii on 1 








roci on 1 


m 


m 


H H 
1 1 




[26] 20.13 








[26] 20.13 


m 


m 


12 


Content-Length 


roci on ^ a 


m 


m 


roci OA 1 /I 


m 


rn 


1 o 


Content-Type 


rod OA -1 c 


m 


m 


rod OA -) c 

[^bj b 


m 


m 


-1 >l 


Cseq 


rooi OA -1 o 


m 


m 


rooi OA H c 

[^ibj dU.AO 


m 


m 


1 


Date 


roci OA i 7 


Co 


Co 


roci OA H 7 


m 


m 


\ D 


Expires 


roci OA i Q 








roci OA 1 Q 


m 


m 




From 


roci OA OA 


m 


m 


roci OA OA 


m 


m 


1 / A 


Geolocation 


roAi o o 

[oyj o.d 


Col 


Col 


roAi o o 
[oyj o.d 


Col 


rtO H 
Col 


■1 7D 

1 /d 


History-Info 


reel >! -i 
[DDJ 4.1 




C^O 


reel a h 
[DO J 4.1 


^OQ 


C^O 


1 o 


Max- Forwards 


roci OA oo 


m 


m 


roci OA oo 


n/a 


n/a 


i Q 

\ y 


iviiivit- version 


roci OA OA 








roci OA OA 


m 


m 


on 


Organization 


rod on oc 

[^bj dO.do 








roci OA oc 








OA A 

^UA 


P-Access-Networl<-lnfo 


rcoi A A 
[0/d.\ 4.4 


Cl li 


Cl O 


rcoi A A 
[O^J 4.4 


Cl li 


C14 




P-Charging-Function- 

MUUI tJootJo 


rcoi A 

[O^J 4.0 


Cl / 


Cl o 


rcoi A ^ 

[O^J 4.0 


Cl / 


Cl o 




r - v_/rid,ryii ly V yoiur 


[O/iJ 4.0 


C 1 


C 1 D 


rc;oi A c 

[OiiJ 4.D 


C 1 


r^-| C 
C 1 D 


OV\V\ 

C.\j\J 


r - Ubcl L/dldUdoc 


FQOl /I 


n/a 


n/a 


rooi A 


*^on 
CoU 


CoU 


^ut 


r - V isiieu-iNeiworK-iu 


rcoi yi Q 


X ^noie li.) 


X 


rcoi A T 
[O^iJ 4.0 


Cl u 


Cl 1 




Path 


roci 4 


04 


OO 


roci A 
LJOJ 4 


m 


OO 




r 1 1 VdUy 


rooi A r> 

[vjoj 4.<:1 




n/a 


rooi 4 o 

[OOJ 4.^ 


oy 


n/a 


91 

c. \ 


r 1 UXy-MULi lUilZdLIUI 1 


roci on OR 


Oo 


Oo 


roci Cn 09. 


n/a 


n/a 


00 


r 1 UAy-ricL|Uli c 


[26] 20.29 





(note 1) 


[26] 20.29 


n/a 


n/a 


22A 


Reason 


[34A] 2 


c23 


c23 


[34A] 2 


c23 


c23 


22B 


Referred-By 


[59] 3 


C25 


c25 


[59] 3 


c26 


c26 


22C 


Request-Disposition 


[56B] 9.1 


c24 


c24 


[56B] 9.1 


n/a 


n/a 


23 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


24 


Route 


[26] 20.34 





n/a 


[26] 20.34 


n/a 


n/a 


24A 


Security-Client 


[48] 2.3.1 


c19 


c20 


[48] 2.3.1 


n/a 


n/a 


24B 


Security- Verify 


[48] 2.3.1 


c20 


c20 


[48] 2.3.1 


c21 


n/a 


25 


Supported 


[26] 20.37 





c29 


[26] 20.37 


m 


m 


26 


Timestamp 


[26] 20.38 


c7 


c7 


[26] 20.38 


c7 


c7 


27 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


28 


User-Agent 


[26] 20.41 








[26] 20.41 








29 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Receiving 



Ref. 



RFC 
status 



Profile 
status 



c1: 
c2: 
c3: 
c4: 

c5: 

c6: 

c7: 

c8: 

c9: 

c10: 

c11: 

c12: 

c13: 

c14: 

c15: 
c16: 

c17: 
c18: 

c19: 
c20: 
c21: 

c22: 
c23: 
c24: 
c25: 
c26: 
c27: 
c28: 
c29: 
c30: 
c31: 



IF A.4/20 THEN m ELSE n/a - 
IF A.4/8 THEN m ELSE n/a - - 
IFA.4/11 THEN ELSE n/a - 
IF A.4/24 THEN o ELSE n/a - 

contacts. 

IF A.4/24 THEN X ELSE n/a - 
contacts. 

IF A.3/4 THEN m ELSE n/a. - 
IF A.4/6 THEN m ELSE n/a - - 
IF A.4/8A THEN m ELSE n/a - 
IF A.4/26 THEN o ELSE n/a - 
IF A.4/33 THEN o ELSE n/a - 
IF A.4/33 THEN m ELSE n/a - 



- SIP specific event notification extension, 
authentication between UA and registrar. 

■ insertion of date in requests and responses. 

■ session initiation protocol extension header field for registering non-adjacent 
session initiation protocol extension header field for registering non-adjacent 

■ S-CCF. 

timestamping of requests. 

- authentication between UA and proxy. 

■ a privacy mechanism for the Session Initiation Protocol (SIP). 

■ the P-Visited-Network-ID extension. 

- the P-Visited-Networl<-ID extension. 

■ the P-Access-Networl<-lnfo header extension, 
the P-Access-Network-lnfo header extension and UE 



the P-Access-Network-lnfo header extension and 



IF A.4/34 THEN o ELSE n/a - 

IF A.4/34 AND (A.3/1 OR A.3/4) THEN o ELSE n/a - - 
or S-CCF. 

IF A.4/34 AND (A.3/4 OR A.3/7A) THEN m ELSE n/a 
S-CCF or AS acting as terminating UA. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

IF A.4/36 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Vector header extension (including S-CCF as 
registrar). 

IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A.4/35 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension (including 

S-CCF as registrar). 

IF A. 4/37 THEN o ELSE n/a - - security mechanism agreement for the session initiation protocol (note 3). 
IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
IF A. 4/37 AND A. 4/2 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol 
and registrar. 

- S-CCF. 

- - the Reason header field for the session initiation protocol. 

- - caller preferences for the session initiation protocol. 

- - the SIP Referred-By mechanism. 

- - the SIP Referred-By mechanism. 

- - SIP specific event notification extension. 

- - an extension to the session initiation protocol for request history information. 
UE. 



IF A.3/4 THEN m ELSE n/a - 
IF A.4/38 THEN o ELSE n/a 
IF A.4/40 THEN o ELSE n/a 
IF A.4/43 THEN m ELSE n/a 
IF A.4/43 THEN o ELSE n/a 
IF A.4/20 THEN o ELSE n/a 
IF A.4/47 THEN m ELSE n/a 
IF A.3/1 THEN m ELSE o - - 



IF A.4/48 THEN m ELSE n/a ■ 

IF A.4/60 THEN m ELSE n/a ■ 



the P-User-Database private header extension. 

SIP location conveyance. 



NOTE 1 : No distinction has been made in these tables between first use of a request on a From/To/Call-ID 

combination, and the usage in a subsequent one. Therefore the use of "o" etc. above has been included 
from a viewpoint of first usage. 
NOTE 2: The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT. 
NOTE 3: Support of this header in this method is dependent on the security mechanism and the security architecture 
which is implemented. 
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Table A.120: Void 
Table A.121: Void 

Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/1 - - Additional for 100 (Trying) response 



Table A.121 A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ret. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 







Prerequisite A.5/19 - - REGISTER response for all status-codes 



Table A.122: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


c8 


c8 


[26] 20.5 


m 


m 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Gall-Info 


[26] 20.9 








[26] 20.9 








2 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


c1 


c1 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


Geolocation 


[89] 3.2 


clO 


clO 


[89] 3.2 


clO 


c10 


9B 


History-Info 


[66] 4.1 


c9 


c9 


[66] 4.1 


c9 


c9 


10 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


11 


Organization 


[26] 20.25 








[26] 20.25 








11A 


P-Access-Network- 1 nfo 


[52] 4.4 


c3 


n/a 


[52] 4.4 


c3 


n/a 


11B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c6 


c7 


[52] 4.5 


c6 


c7 


lie 


P-Charging-Vector 


[52] 4.6 


c4 


c5 


[52] 4.6 


c4 


c5 


11D 


Privacy 


[33] 4.2 


c2 


n/a 


[33] 4.2 


c2 


n/a 


11E 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


11F 


Server 


[26] 20.35 








[26] 20.35 








12 


Timestamp 


[26] 20.38 


c2 


c2 


[26] 20.38 


m 


m 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 








[26] 20.41 








14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


(note) 





[26] 20.43 
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Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Receiving 



Ref. 



RFC 
status 



Profile 
status 



c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for tlie Session Initiation Protocol (SIP). 

c3: IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

c4: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

c5: IF A.4/36 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Vector header extension (including S-CCF as 

registrar). 

c6: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c7: IF A.4/35 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension (including 

S-CCF as registrar). 
c8: IF A.6/18 THEN m ELSE o - - 405 (Method Not Allowed). 

c9: IF A.4/47 THEN m ELSE n/a - - an extension to the session initiation protocol for request history information. 

c1 0: IF A.4/60 THEN m ELSE n/a - - SIP location conveyance. 



NOTE: For a 488 (Not Acceptable Here) response, RFC 3261 [26] gives the status of this header as SHOULD 
rather than OPTIONAL. 



Prerequisite A.5/19 - - REGISTER response 
Prerequisite: A.6/102 - - Additional for 2xx response 

Table A.123: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 







[26] 20.1 







1A 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


IB 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


2 


Allow-Events 


[28] 7.2.2 


c12 


c12 


[28] 7.2.2 


c13 


c13 


3 


Authentication-Info 


[26] 20.6 


c6 


c6 


[26] 20.6 


c7 


c7 


5 


Contact 


[26] 20.10 








[26] 20.10 


m 


m 


5A 


P-Associated-URI 


[52] 4.1 


c8 


c9 


[52] 4.1 


clO 


c11 


6 


Path 


[35] 4 


c3 


c3 


[35] 4 


c4 


c4 


8 


Service-Route 


[38] 5 


c5 


c5 


[38] 5 


c5 


c5 


9 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



c1: 

c2: 
c3: 

c4: 

c5: 

c6: 

c7: 

c8: 

c9: 

clO 

c11 

c12 

c13 



IF (A.3/4 AND A.4/2) THEN m ELSE n/a. - - S-CCF acting as registrar 
IF A.3/4 OR A.3/1THEN m ELSE n/a. - - S-CCF or UE. 
IF A.4/24 THEN m ELSE n/a 
contacts. 

IF A.4/24 THEN ELSE n/a 
contacts. 

IF A. 4/28 THEN m ELSE n/a - - session initiation protocol extension header field for service route discovery 
during registration. 
IF A.4/8 THEN ELSE n/a - 
IFA.4/8THEN m ELSE n/a • 



- session initiation protocol extension header field for registering non-adjacent 

- session initiation protocol extension header field for registering non-adjacent 



authentication between UA and registrar, 
authentication between UA and registrar. 
IF A.4/2 AND A.4/31 THEN m ELSE n/a - - P-Associated-URI header extension and registrar. 
IF A.3/1 AND A.4/31 THEN m ELSE n/a - - P-Associated-URI header extension and S-CCF. 
IF A.4/31 THEN o ELSE n/a - - P-Associated-URI header extension. 
IF A.4/31 AND A.3/1 THEN m ELSE n/a - - P-Associated-URI header extension and UE. 
IF A.4/20 THEN o ELSE n/a - - SIP specific event notification extension. 
IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 
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Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/103 OR A.6/104 OR A.6/105 OR A.6/106 - - Additional for 3xx - 6xx response 



Table A.123A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/103 OR A.6/35 - - Additional for 3xx or 485 (Ambiguous) response 



Table A.124: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/14 - - Additional for 401 (Unauthorized) response 

Table A.125: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


c1 


X 


[26] 20.27 


Cl 


X 


6 


Security-Server 


[48] 2 


X 


X 


[48] 2 


n/a 


c2 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 : IF A. 4/8 THEN m ELSE n/a - - support of authentication between UA and registrar. 

c2: IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/5 1 - - Additional for 
404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal 
Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (DecUne) response 

Table A.126: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Retry-After 


[26] 20.33 








[26] 20.33 
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Table A.127: Void 

Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.128: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Proxy-Authenticate 


[26] 20.27 


c1 


X 


[26] 20.27 


c1 


X 


9 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1 : IF A.4/8 THEN m ELSE n/a - - support of authentication between UA and registrar. 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.129: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


0.1 


At least one of these capabilities is supported. 













Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/27 - - Additional for 420 (Bad Extension) response 

Table A.130: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


8 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/28 OR A.6/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.130A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


3 


Security-Server 


[48] 2 


c2 


c2 


[48] 2 


Cl 


c1 



cl : IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c2: IF A. 4/37 AND A. 4/2 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol 

and registrar. 
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Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/29 - - Additional for 423 (Interval Too Brief) response 



Table A.131 : Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Min-Expires 


[26] 20.23 


m 


m 


[26] 20.23 


m 


m 
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Table A.132: Void 
Table A.133: Void 

A.2.2.2 Major capabilities 



Table A.162: lUlajor capabilities 



ItAm 
llclll 


UUco lllc IliipiclllcllldllUII oUppur I 










Capabilities within main protocol 








Q 
O 


initiate session release? 




X 


C<i / 


4 


stateless proxy behaviour? 


[26] 16.11 


0.1 


c29g2§ 


5 


stateful proxy behaviour? 


[26] 16.2 


0.1 


c28g29 


6 


forking of initial requests? 


[26] 16.1 


c1 


c31 


7 


support of indication of TLS connections 
in the Record-Route header on the 

upstream side? 


[26] 16.7 





n/a 


8 


support of indication TLS connections in 
the Record-Route header on the 
downstream side? 


[26] 16.7 





n/a 


8A 


authentication between UA and proxy? 


[26] 20.28, 
22.3 





x 


9 


insertion of date in requests and 

responses? 


[26] 20.17 








10 


suppression or modification of alerting 
information data? 


[26] 20.4 








11 


reading the contents of the Require 
header before proxying the request or 

response? 


[26] 20.32 








12 


adding or modifying the contents of the 
Require header before proxying the 
REGISTER request or response 


[26] 20.32 





m 


13 


adding or modifying the contents of the 
Require header before proxying the 
request or response for methods other 
than REGISTER? 


[26] 20.32 








14 


being able to insert itself in the 
subsequent transactions in a dialog 
(record-routing)? 


[26] 1 6.6 





c2 


15 


the requirement to be able to use 
separate URIs in the upstream direction 
and downstream direction when record 
routeing? 


[26] 16.7 


c3 


c3 


16 


reading the contents of the Supported 
header before proxying the response? 


[26] 20.37 








17 


reading the contents of the Unsupported 
header before proxying the 420 
response to a REGISTER? 


[26] 20.40 





m 


18 


reading the contents of the Unsupported 
header before proxying the 420 

response to a method other than 
REGISTER? 


[26] 20.40 








19 


the inclusion of the Error-Info header in 
3xx - 6xx responses? 


[26] 20.18 








19A 


reading the contents of the Organization 
header before proxying the request or 
response? 


[26] 20.25 








19B 


adding or concatenating the 
Organization header before proxying the 
request or response? 


[26] 20.25 








19C 


reading the contents of the Gall-Info 
header before proxying the request or 
response? 


[26] 20.925 








19D 


adding or concatenating the Gall-Info 
header before proxying the request or 
response? 


[26] 20.925 
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Item 


Does the implementation support 


Reference 


RFC status 


Profile status 




Capabilities within main protocol 








19E 


delete Contact headers from 3xx 
responses prior to relaying the 
response? 


[26] 20 










Extensions 








20 


the SIP INFO method r 


[25] 








21 


reliability of provisional responses in 

bir f 


[27] 





i 


22 


the REFER method? 


[36] 








23 


integration of resource management and 
SIP? 


[30] [64] 





i 


24 


the bIP UPDATE method r 


[29] 


c4 


i 


26 


SIP extensions for media authorization? 


[31] 





c7 


27 


SIP specific event notification 


[28] 





i 


28 


the use of NOTIFY to establish a dialog 


[28] 4.2 





n/a 


29 


Session Initiation Protocol Extension 
Header Field for Registering Non- 
Adjacent Contacts 


[35] 





c6 


30 


extensions to the Session Initiation 

Protocol (SIP) for asserted identity within 
trusted networks 


[34] 





m 


30A 


act as first entity within the trust domain 
for asserted identity 


[34] 


c5 


c8 


30B 


act as subsequent entity within trust 
network that can route outside the trust 
network 


[34] 


c5 


c9 


31 


a privacy mechanism for the Session 
Initiation Protocol (SIP) 


[33] 





m 


31A 


request of privacy by the inclusion of a 
Privacy header 


[33] 


n/a 


n/a 


31B 


application of privacy based on the 
received Privacy header 


[33] 


clO 


c12 


31C 


passing on of the Privacy header 
transparently 


[33] 


clO 


c13 


31 D 


application of the privacy option "header" 
such that those headers which cannot 
be completely expunged of identifying 
information without the assistance of 
intermediaries are obscured? 


[33] 5.1 


X 


X 


31E 


application of the privacy option 
"session" such that anonymization for 
the session(s) initiated by this message 
occurs? 


[33] 5.2 


n/a 


n/a 


31 F 


application of the privacy option "user" 
such that user level privacy functions are 
provided by the network? 


[33] 5.3 


n/a 


n/a 


31G 


application of the privacy option "id" 
such that privacy of the network 
asserted identity is provided by the 
network? 


[34] 7 


c11 


c12 


31H 


application of the privacy option "history" 
such that privacy of the History-Info 
header is provided by the network? 


[66] 7.2 


c34 


c34 


32 


Session Initiation Protocol Extension 
Header Field for Service Route 
Discovery During Registration 


[38] 





c30 


33 


a messaging mechanism for the Session 
Initiation Protocol (SIP) 


[50] 





m 


34 


Compressing the Session Initiation 
Protocol 


[55] 





c7 


35 


private header extensions to the session 
initiation protocol for the 3rd-Generation 

Partnership Project (3GPP)? 


[52] 





m 


36 


the P-Associated-URI header extension? 


[52] 4.1 


c14 


c15 


37 


the P-Called-Party-ID header extension? 


[52] 4.2 


c14 


c16 


38 


the P-Visited-Network-ID header 


[52] 4.3 


c14 


c17 
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Item 


Does the implementation support 


Reference 


RFC status 


Profile status 




Capabilities within main protocol 










extension? 








39 


reading, or deleting the P-Visited- 
Network-ID header before proxying the 
request or response? 


[52] 4.3 


c18 


n/a 


41 


the P-Access-Network-lnfo header 
extension? 


[52] 4.4 


c14 


c19 


42 


act as first entity within the trust donnain 
for access network information? 


[52] 4.4 


c20 


c21 


43 


act as subsequent entity within trust 
network for access network information 

that can route outside the trust network? 


[52] 4.4 


c20 


c22 


44 


the P-Charging-Function-Addresses 
header extension? 


[52] 4.5 


c14 


m 


44A 


adding, deleting or reading the 
P-Charging-Function-Addresses header 
before proxying the request or 
response? 


[52] 4.6 


c25 


c26 


45 


the P-Charging-Vector header 
extension? 


[52] 4.6 


c14 


m 


46 


adding, deleting, reading or modifying 
the P-Charging-Vector header before 
proxying the request or response? 


[52] 4.6 


c23 


c24 


47 


security mechanism agreement for the 
session initiation protocol? 


[48] 





c7 


48 


the Reason header field for the session 
initiation protocol 


[34A] 








49 


an extension to the session initiation 
protocol for symmetric response routeing 


[56A] 





m 


50 


caller preferences for the session 
initiation protocol? 


[568] 


c33 


c33 


50A 


the proxy-directive within caller- 
preferences? 


[568] 9.1 


0.4 


0.4 


50B 


the cancel-directive within caller- 
preferences? 


[56B] 9.1 


0.4 


0.4 


50C 


the fork-directive within caller- 
preferences? 


[56B] 9.1 


0.4 


c32 


50D 


the recurse-directive within caller- 
preferences? 


[56B] 9.1 


0.4 


0.4 


50E 


the parallel-directive within caller- 
preferences? 


[568] 9.1 


0.4 


c32 


50 F 


the queue-directive within caller- 
preferences? 


[568] 9.1 


0.4 


0.4 


51 


an event state publication extension to 
the session initiation protocol? 


[70] 





m 


52 


SIP session timer? 


[58] 








53 


the SIP Referred-By mechanism? 


[59] 








54 


the Session Initiation Protocol (SIP) 
"Replaces" header? 


[60] 








55 


the Session Initiation Protocol (SIP) 

"Join" header? 


[61] 








56 


the caller capabilities? 


[62] 








57 


an extension to the session initiation 
protocol for request history information? 


[66] 








58 


Rejecting anonymous requests in the 

session initiation protocol? 


[67] 








59 


session initiation protocol URIs for 
applications such as voicemail and 
interactive voice response 


[68] 








bO 


the P-User-Database private header 
extension? 


rool 

[82] 





©c95 


61 


Session initiation protocol's non-INVITE 

transactions? 


[83] 


m 


m 


62 


a uniform resource name for services 


[69] 


n/a 


c35 


63 


obtaining and using GRUUs in the 
Session Initiation Protocol (SIP) 


[93] 





c36 
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Capabilities within main protocol 








64 


an extension to the session initiation 
protocol for request cpc information? 


[95] 





c37 


65 


the Stream Control Transmission 
Protocol (SCTP) as a Transport for the 
Session Initiation Protocol (SIP)? 


[96] 





(note2) 


66 


the SIP P-Profle-Key private header 

extension? 


[97] 





c41 


66A 


making the first query to the database in 
order to populate the P-Profile-Key 
header? 


[97] 


c38 


c39 


66B 


using the information in the P-Profile- 
Key header? 


[97] 


c38 


c40 


67 


managing client initiated connections in 
SIP? 


[92] 1 1 





c42 


69 


multiple-recipient MESSAGE requests in 

the session initiation protocol 


[104] 


n/a 


n/a 


70 


SIP location conveyance? 


[89] 





m 


70A 


addition or modification of location in a 

SIP method? 


[89] 


c44 


c45 


70B 


passes on locations in SIP method 
without modification? 


[89] 


c44 


c46 


71 


referring to multiple resources in the 

session initiation protocol? 


[105] 


n/a 


n/a 


72 


conference establishment using request- 
contained lists in the session initiation 
protocol? 


[106] 


n/a 


n/a 


73 


subscriptions to request-contained 
resource lists in the session initiation 
protocol? 


[107] 


n/a 


n/a 


74 


dialstring parameter for the session 
initiation protocol uniform resource 
identifier? 


[103] 





n/a 


75 


the P-Answer-State header extension to 
the session initiation protocol for the 
open mobile alliance push to tall< over 

cellular? 


[111] 





c60 


76 


the SIP P-Early-Media private header 
extension for authorization of early 
media? 


[109] 8 





c51 


81 


addressing an amplification vulnerability 
in session initiation protocol forking 

proxies? 


[117] 


c52 


c52 


82 


the remote application identification of 
applying signalling compression to SIP 


[79] 9.1 





c7 


83 


a session initiation protocol media 
feature tag for MIME application sub- 
types? 


[120] 





c53 


84 


identification of communication services 
in the session initiation protocol? 


[121] 





c54 


84A 


act as authentication entity within the 
trust domain for asserted service? 


[121] 


c55 


c56 


85 


XML Schema for PSTN? 


[ANNEX ZBl 


m 


c61 
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Item 


Does the Implementation support 


Reference 


RFC status 


Profile status 




Capabilities within main protocol 









c1 : IF A.1 62/5 THEN o ELSE n/a - - stateful proxy behaviour. 

C2: IF A.3/2 OR A.3/9A OR A.3/4 THEN m ELSE o - - P-CSCF, IBCF (THIG) or S-CCF. 

C3: IF (A.1 62/7 AND NOT A.1 62/8) OR (NOT A.I 62/7 AND A.I 62/8) THEN m ELSE IF 



A.162/14 THEN o ELSE n/a - - TLS interworking with non-TLS else proxy insertion. 
c4: IF A.1 62/23 THEN m ELSE o - - integration of resource management and SIP. 

c5: IF A.1 62/30 THEN o ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networl<s. 
c6: IF A.3/2 OR A.3/9A THEN m ELSE n/a - - P-CSCF or IBCF (THIG). 

c7: IF A.3/2 THEN m ELSE n/a - - P-CSCF. 

c8: IF A.3/2 AND A.1 62/30 THEN m ELSE n/a - - P-CSCF and extensions to the Session 

Initiation Protocol (SIP) for asserted identity within trusted networks. 
c9: IF A.3/2 AND A.1 62/30 THEN m ELSE IF A.3/7C AND A.1 62/30 THEN o ELSE n/a - - 

S-CCF or AS acting as proxy and extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks (note 1). 
clO: IF A.1 62/31 THEN 0.2 ELSE n/a - - a privacy mechanism for the Session Initiation 

Protocol (SIP). 

c1 1 : IF A.162/31 B THEN o ELSE x - - application of privacy based on the received Privacy 
header. 

c12: IF A.162/31 AND A.3/4 THEN m ELSE n/a - - S-CCF. 

Cl3: IF A.162/31 AND (A.3/2 OR A.3/3 OR A.3/7C OR A.3/9A) THEN m ELSE n/a - - 

P-CSCF or l-CSCF or AS acting as a SIP proxy or IBCF (THIG). 
c14: IF A.1 62/35 THEN 0.3 ELSE n/a - - private header extensions to the session initiation 

protocol for the 3rd-Generation Partnership Project (3GPP). 
c1 5: IF A.1 62/35 AND (A.3/2 OR A.3/3 OR A.3/9A) THEN m THEN o ELSE n/a - - private 

header extensions to the session initiation protocol for the 3rd-Generation Partnership 

Project (3GPP) and P-CSCF or l-CSCF or IBCF (THIG). 
c16: IF A.1 62/35 AND (A.3/2 OR A.3/3 OR A.3/4 OR A.3/9A) THEN m ELSE n/a - - private 

header extensions to the session initiation protocol for the 3rd-Generation Partnership 

Project (3GPP) and P-CSCF or l-CSCF or S-CCF or IBCF (THIG). 
c1 7: IF A.1 62/35 AND (A.3/2 OR A.3/3 OR A.3/9A) THEN m ELSE n/a - - private header 

extensions to the session initiation protocol for the 3rd-Generation Partnership Project 

(3GPP) and P-CSCF or l-CSCF or IBCF (THIG). 
c18: IF A.1 62/38 THEN o ELSE n/a - - the P-Visited-Network-ID header extension. 
c19: IF A.1 62/35 AND (A.3/2 OR A.3.3 OR A.3/4 OR A.3/7 THEN m ELSE n/a - - private 

header extensions to the session initiation protocol for the 3rd-Generation Partnership 

Project (3GPP) and P-CSCF, l-CSCF, S-CCF, AS acting as a proxy. 
c20: IF A.162/41 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c21 : IF A.1 62/41 AND A.3/2 THEN m ELSE n/a - - the P-Access-Network-lnfo header 

extension and P-CSCF. 
c22: IF A.1 62/41 AND A.3/4 THEN m ELSE n/a - - the P-Access-Network-lnfo header 

extension and S-CCF. 
c23: IF A.162/45 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c24: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
c25: IF A.162/44 THEN o ELSE n/a - - the P-Charging-Function-Addresses header 

extension. 

c26: IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Function Addresses header 

extension. 

c27: IF A.3/2 OR A.3/4 THEN m ELSE x - - P-CSCF or S-CCF. 

c28: IF A.3/2 OR A.3/3 OR A.3/4 OR A.3/6 th e n THEN m ELSE o^ - - P-CSCF . l-CSCF or 
S-CCF of MGCF . 

c29: IF A.3/2 OR A.3/4 OR A.3/6 th e n o THEN n/a ELSE m IF A.3/3 THENo ELSE 0.8 - - 

P-CSCF or S-CCF or l-CSCF -oa4GGF. 
c30: IF A.3/2 o ELSE i - - P-CSCF. 
C31 : IF A.3/4 THEN m ELSE x - - S-CCF. 
c32: IF A.3/4 THEN m ELSE 0.4- -S-CCF. 

c33: IF A.162/50A OR A.162/50B OR A.162/50C OR A.162/50D OR A.162/50E OR 

A.162/50F THEN m ELSE n/a - - support of any directives within caller preferences for 
the session initiation protocol. 

c34: IF A.1 62/57 THEN m ELSE n/a - - an extension to the session initiation protocol for 

request history information. 
C35: IF A.3/2 OR A.3/1 1 THEN m ELSE n/a - - P-CSCF, E-CSCF. 
c36: IF A.3/4 THEN m ELSE n/a - - S-CCF. 

C37: IF A.3/2 OR A.3/3 OR A.3/4 OR A.3.5 OR A.3/6 OR A.3/7 OR A.3/8 OR A.3/9A THEN o 
ELSE n/a - - cpc URI parameter. 

c38: IF A.1 62/66 THEN o ELSE n/a - - the SIP P-Profile-Key private header. 

c39: IF A.1 62/66 AND (A.3/3 OR A.3/9A) THEN m ELSE n/a - - the SIP P-Profile-Key private 

header, l-CSCF or IBCF (THIG). 
c40: IF A.1 62/66 AND A.3/4 THEN m ELSE n/a - - the SIP P-Profile-Key private header, 

S-CCF 

c41 : IF A.3/3 OR A.3/4 OR A.3/9A THEN o ELSE n/a - - l-CSCF or S-CCF or IBCF (THIG). 
c42: IF A.3/2 OR A.3/4 THEN o ELSE n/a^^^^-CSCF, S-CCF. 
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NOTE 1 : An AS acting as a proxy may be outside the trust domain, and tlierefore not able to 
support tine capability for that reason; in this case it is perfectly reasonable for the 
header to be passed on transparently, as specified in the PDU parts of the profile. 

NOTE 2: Not applicable over Gm reference point (UE - P-CSCF). 
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A.2.2.4.3 BYE method 

Prerequisite A. 163/2 - - BYE request 



Table A.167: Supported headers within the BYE request 
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c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE 1 - - insertion of date in requests and responses. 

c3: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c4: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c6: IF A. 1 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions In a 

dialog. 

c8; IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c9: IF A.1 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted Identity 

within trusted networks. 

c10: IF A.162/30Aor A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c1 1 : IF A.1 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c12: IF A.1 62/31 DOR A.1 62/31 G THEN m ELSE IF A.1 62/31 C THEN 1 ELSE n/a -- application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c13: IF A.1 62/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network Information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c14: IF A.162/43 THEN m ELSE IF A.162/41 THEN 1 ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c1 5: IF A.1 62/45 THEN m ELSE n/a - - the P-Charglng-Vector header extension. 

c16: IF A. 162/46 THEN m ELSE IF A. 162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charglng-Vector header 
extension. 

c17: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c1 8: IF A.1 62/44A THEN m ELSE IF A.1 62/44 THEN I ELSE n/a - - adding, deleting or reading the P-Charging- 

Functlon-Addresses header before proxying the request or response, or the P-Charglng-Function- 

Addresses header extension. 

c1 9: IF A. -l /S? A.1 62.47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c20: IF A.1 62/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c21 : IF A. 162/48 THEN 1 ELSE n/a - - the Reason header field for the session initiation protocol. 

c22: IF A.162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c23: IF A.1 62/50 THEN i ELSE n/a - - caller preferences for the session Initiation protocol. 

c24: IF A.1 62/53 THEN I ELSE n/a - - the SIP Referred-By mechanism. 

c25: IF A.1 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c26: IF A. 162/70 THEN m ELSE n/a - - SIP location conveyance. 

c27: IF A.162/70A THEN m ELSE IF A.162/70B THEN i ELSE n/a - - addition or modification of location In a SIP 

method, passes on locations In SIP method without modification. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 
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Table A.168: Void 
Table A.169: Void 

Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 



Table A.169A: Supported headers within the BYE response 
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IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a 


- - stateful proxy behaviour that inserts date, or 


c2: 


stateless proxies. 

IF A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/3 - - BYE response for all remaining status codes 



Table A.170: Supported headers within the BYE response 
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User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



cl : IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c3: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 



c4; IF A. 162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c5: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c6: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c7: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c8: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c9: IF A.I 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

cl 0: IF A.I 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c11: IF A.162/44ATHEN m ELSE IF A. 162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c12: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c13: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c14: IF A. 162/11 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 
the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

cl 5: IF A.I 62/70 THEN m ELSE n/a - - SIP location conveyance. 

cl 6: IF A.I 62/70A THEN m ELSE IF A.I 62/70B THEN i ELSE n/a - - addition or modification of location in a SIP 
method, passes on locations in SIP method without modification. 



Prerequisite A. 163/3 - - BYE response 
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Prerequisite: A. 164/102 - - Additional for 2xx response 



Table A.171 : Supported headers within the BYE response 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


i 


c1 


1 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 




2 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 




c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.1 62/1 5 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/3 - - BYE response 

Prerequisite: A.164/103 OR A.164/104 OR A.164/105 OR A.164/106 - - Additional for 3xx - 6xx response 



Tabie A.171 A: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/3 - BYE response 

Prerequisite: A.164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 



Table A.1 72: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 


Profile 


Ref. 


RFC 


Profile 








status 


status 




status 


status 


1 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


cl 


c1: 


IF A.1 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 



Table A.1 73: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 
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Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/1 7 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/42 OR A. 164/45 OR A. 164/50 OR 
A.164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 



Table A.174: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 



Table A.175: Void 

Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.176: Supported headers within the BYE response 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 



Table A.177: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 



Tabie A.178: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/28 OR A. 164/41 A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 



Table A.178A: Supported headers within the BYE response 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security meclianism agreement for the session initiation protocol. 
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Table A.179: Void 
Table A.180: Void 

A.2.2.4.7 INVITE method 

Prerequisite A. 163/8 - - INVITE request 



Table A.204: Supported headers within the INVITE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


1 


1A 


Accept-Contact 


[56B] 9.2 


c34 


c34 


[56B1 9.2 


c34 


c35 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


1 


i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


1 


1 


4 


Alert- Info 


[26] 20.4 


c2 


c2 


[26] 20.4 


c3 


c3 


5 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


6 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


c1 


Cl 


8 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


1 


i 


9 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


10 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c12 


c12 


11 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


1 


12 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


c6 


13 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


1 


c6 


14 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


c6 


15 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


16 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c6 


17 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


18 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c4 


c4 


19 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


20 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


20A 


Geolocation 


[89] 3.2 


c47 


c47 


[89] 3.2 


c48 


c48 


20B 


History-Info 


[66] 4.1 


c43 


c43 


[66] 4.1 


c43 


c43 


21 


In-Reply-To 


[26] 20.21 


m 


m 


[26] 20.21 


1 


1 


21A 


Join 


[61] 7.1 


c41 


c41 


[61] 7.1 


c42 


c42 


22 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


23 


IVIIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c6 


23A 


Min-SE 


[58] 5 








[58] 5 








24 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c5 


c5 


24A 


P-Access-Network-lnfo 


[52] 4.4 


c28 


c28 


[52] 4.4 


c29 


c30 


24B 


P-Asserted-ldentity 


[34] 9.1 


c15 


c15 


[34] 9.1 


c16 


c16 


24C 


P-Asserted-Service 


[121] 4.1 


c53 


c53 


[121]4.1 


c54 


c54 


24D 


P-Called-Party-ID 


[52] 4.2 


c19 


c19 


[52] 4.2 


c20 


c21 


24E 


P-Charging-Function- 
Addresses 


[52] 4.5 


c26 


c27 


[52] 4.5 


c26 


c27 


24F 


P-Charging-Vector 


[52] 4.6 


c24 


c24 


[52] 4.6 


c25 


c25 


24G 


P-Early-Media 


[109] 8 





c50 


[109] 8 





c51 


25 


P-Media-Authorization 


[31] 5.1 


c9 


X 


[31] 5.1 


n/a 


n/a 


25A 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c14 


c14 


25B 


P-Preferred-Service 


[121] 4.2 


X 


X 


[121] 4.2 


c52 


c52 


258 


P-Profile-Key 


[9715 


c45 


c45 


[9715 


c46 


c46 


25C 


P-User-Database 


[82] 4 


c44 


c44 


[8214 


c44 


c44 


25D 


P-Visited-Network-ID 


[52] 4.3 


c22 


n/a 


[52] 4.3 


c23 


n/a 


26 


Priority 


[26] 20.26 


m 


m 


[26] 20.26 


i 


i 


26A 


Privacy 


[33] 4.2 


c17 


c17 


[33] 4.2 


c18 


c18 


27 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c13 


c13 


28 


Proxy-Require 


[26] 20.29, 
[34] 4 


m 


m 


[26] 20.29, 
[34] 4 


m 


m 


28A 


Reason 


[34A] 2 


c32 


c32 


[34A] 2 


c33 


c33 


29 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c11 


c11 


30 


Referred-By 


[59] 3 


c37 


c37 


[59] 3 


c38 


c38 


31 


Reject-Contact 


[56B] 9.2 


c34 


c34 


[56B1 9.2 


c34 


c35 


31A 


Replaces 


[60] 6.1 


c39 


c39 


[60] 6.1 


c40 


c40 
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ItGm 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


ol b 


Reply-To 


rod on o^ 


m 


m 


rooi on o^ 


i 


i 


O 1 D 


riequesi-uisposiiion 


[OOBJ y.i 


Co4 


Co4 


[bbbj 9.1 


Co4 


r\n A 

Co4 


QO 
Oil 


Require 


roci on OO 


m 


m 


rod OA OO 
[db\ <i\J.6<L 


CI 


CI 


OO 


Route 


rOCM OA o 

[26J <£0.o4 


m 


m 


rOAl OA O y1 

<i0.34 


m 


m 


ooA 


Security-Client 


[48J <i.3.1 


X 


X 


Tyl Ol O O ^ 

[48] 


C31 


«0 H 

Col 


OOD 


Security-Verify 




X 


X 


r^Qi O O H 


Co 1 


^o-( 

Co 1 


ooU 


oession-txpires 


[5814 


c36 


c36 


[5814 


c36 


c36 


34 


Subject 


[26] 20.36 


m 


m 


[26] 20.36 


i 




35 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c8 


c8 


36 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 




37 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


38 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 




39 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.I 62/1 THEN n/a ELSE m - - suppression or modification of alerting information data. 

c3: IF A.I 62/1 THEN m ELSE i - - suppression or modification of alerting information data. 

c4: IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 

c5: IF A.I 62/1 9A OR A.I 62/1 9B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c6: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CCF. 

c7: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying the 

request or response or adding or modifying the contents of the Require header before proxying the request 
or response for methods other than REGISTER. 

c8: IF A.I 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the response. 

c9: IF A. 162/26 THEN m ELSE n/a - - SIP extensions for media authorization. 

c1 1 : IF A.162/14 THEN m ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 
dialog. 

c12: IF A.162/1 9C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 
c13: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c14: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 
c15: IF A. 162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 
within trusted networks. 

c16: IF A.162/30Aor A.162/30BTHEN m ELSE i -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c17: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c18: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c19: IF A.162/37 THEN m ELSE n/a - - the P-Called- Party- ID header extension. 
c20: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c21 : IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND (A.3/3 OR A.3/9A) THEN i ELSE n/a - - the 

P-Called-Party-ID header extension and P-CSCF or (l-CSCF or IBCF (THIG)). 
c22: IF A.I 62/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c23: IF A.162/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 
request or response. 

c24: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c25: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the 
P-Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c26: IF A.I 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c27: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function-Addresses 

header extension. 

c28: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c29: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c30: IF A.I 62/43 OR (A.I 62/41 AND A.3/2) THEN m ELSE IF A.I 62/41 THEN i ELSE n/a - - act as subsequent 
entity within trust network for access network information that can route outside the trust network, the 
P-Access-Network-lnfo header extension (with or without P-CSCF). 

c31 : IF A.^/37 A. 162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c32: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c33: IF A.162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

c34: IF A.162/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 
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Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Receiving 



Ref. 



RFC 
status 



Profile 
status 



c35: 

c36 
c37 
c38 
c39 
c40 
c41 
c42 
c43 

c44: 
c45: 

c46 
c47 
c48 

c50: 

c51: 

c52 
c53 
c54 



IF A.1 62/50 AND A.4/3 THEN m ELSE IF A.1 62/50 AND NOT A.4/3 THEN i ELSE n/a ■ 
for the session initiation protocol, and S-CCF. 



■ caller preferences 



IF A.1 62/52 THEN m ELSE n/a 
IF A.162/53 THEN i ELSE n/a - - 
IF A.1 62/53 THEN m ELSE n/a - 
IF A.1 62/54 THEN m ELSE n/a - 
IF A.1 62/54 THEN 1 ELSE n/a - - 
IF A.1 62/55 THEN m ELSE n/a - 
IF A.1 62/55 THEN i ELSE n/a - - 
IF A.1 62/57 THEN m ELSE n/a - 
information. 

IF A.1 62/60 THEN m ELSE n/a - 
IF A.1 62/66A THEN m ELSE n/a 
Key header. 

IF A.162/66B THEN m ELSE n/a 
IF A. 162/70 THEN m ELSE n/a - 



the SIP session timer, 
the SIP Referred-By mechanism. 

- the SIP Referred-By mechanism. 

- the Session initiation Protocol (SIP) "Replaces" header, 
the Session Initiation Protocol (SIP) "Replaces" header. 

- the Session Initiation Protocol (SIP) "Join" header, 
the Session Initiation Protocol (SIP) "Join" header. 

- an extension to the session initiation protocol for request history 

- the P-User-Database private header extension. 

- - mal<ing the first query to the database in order to populate the P-Profile- 



- using the information in the P-Profile-Key header. 
SIP location conveyance. 

IF A.162/70A THEN m ELSE IF A.162/70B THEN i ELSE n/a - - addition or modification of location in a SIP 
method, passes on locations in SIP method without modification. 

IF A.1 62/76 THEN m ELSE n/a - - the SIP P-Early-Media private header extension for authorization of early 

media. 

IF A.1 62/76 THEN (IF A.3/2 THEN m ELSE i) ELSE n/a - - P-CSCF, using the information in the P-Early- 
Media header. 

IF A.162/84A THEN m ELSE n/a - - act as authentication entity within the trust domain for asserted service. 
IF A.1 62/84 THEN m ELSE n/a - - identification of communication services in the session initiation protocol. 
IF A.1 62/84 OR A.162/30B THEN m ELSE i - - identification of communication services in the session 

initiation protocol or subsequent entity within trust networl< that can route outside the trust networl<. 

c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



NOTE: 



Table A.205: Void 

Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 



Table A.206: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a 


- stateful proxy behaviour that inserts date, or 


c2: 


stateless proxies. 

IF A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/9 - - INVITE response for all remaining status-codes 



Table A.207: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


nn 


[26] 20.5 


i 


i 


1 


« 1 1 1 nv 

uall-IU 


[26J 20.8 


m 


m 


[26J 20.8 


m 


m 


1 A 


Oall-lnto 


[26] 20.9 


m 


m 


[26] 20.9 


c4 


c4 


2 


Content-Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


c3 


3 


Content-Encoding 


[26] 20.1 2 


m 


m 


[26] 20.12 


i 


c3 


4 


Content-Language 


[26] 20.1 3 


m 


m 


[26] 20.13 


i 


c3 


5 


Content-Lengtfn 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c3 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c1 


c1 


8A 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


History-Info 


[66] 4.1 


c17 


c17 


[66] 4.1 


c17 


c17 


10 


IVIIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


1 1 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


1 1 A 


P- Access- N etworl<- 1 nf o 


[52] 4.4 


c14 


c14 


[52] 4.4 


c15 


c15 


1 1 B 


P-Asserted-ldentity 


[34] 9.1 


c6 


c6 


[34] 9.1 


c7 


c7 


1 1C 


P-Charglng-Functlon- 
Addresses 


[52] 4.5 


c12 


c12 


[52] 4.5 


c13 


c13 


1 1 D 


P-Cliarging-Vector 


rcoi A C 
[O^J 4.0 


CI u 


CI u 




CI 1 


C \ \ 


-I -I p 
1 1 1 


r - r rcTerrea-iueniiiy 


[34] 9.2 


X 


X 


[34] 9.2 


c5 


n/a 


11F 


Privacy 


[33] 4.2 


c8 


c8 


[33] 4.2 


c9 


c9 


11G 


Reply-To 


[26] 20.31 


m 


m 


[26] 20.31 






11H 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c16 


c16 


111 


Server 


[26] 20.35 


m 


m 


[26] 20.35 






11J 


Reason 


Annex ZB 




c20 


Annex ZB 




c20 


12 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 






13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 






14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 
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c1 : IF A. 1 62/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/19AOR A.162/19B THEN m ELSE i - - reading, adding or concatenating tlie Organization lieader. 

c3: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CCF. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c5: IF A.1 62/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c6: IF A. 162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c7: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networl<s or subsequent entity within trust networl< that can route outside the 
trust networl<. 

c8: IF A.1 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c9: IF A.1 62/31 D OR A.1 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c1 0: IF A.1 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c11: IF A.1 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the 
P-Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c12: IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c13: IF A.162/44A THEN m ELSE IF A.1 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function-Addresses 

header extension. 

c14: IF A.1 62/43 THEN x ELSE IF A.1 62/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c15: IF A.1 62/43 THEN m ELSE IF A.1 62/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c16: IF A.1 62/11 OR A.1 62/1 3 THEN m ELSE i - - reading the contents of the Require header before proxying the 
request or response or adding or modifying the contents of the Require header before proxying the request 
or response for methods other than REGISTER. 

c1 7: IF A.1 62/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 
information. 

c18: IF A.162/70 THEN m ELSE n/a - - SIP location conveyance. 

c19: IF A.162/70A THEN m ELSE IF A.162/70B THEN i ELSE n/a - - addition or modification of location in a SIP 

method, passes on locations in SIP method without modification. 
c20: IF A.4/38 THEN o ELSE n/a - - the Reason header field for the session initiation protocol. 



Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A.164/101 A - - Additional for 180 response 



Table A.208: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


5 


P-Answer-State 


[111] 


c13 


c13 


[111] 


c14 


c14 


5A 


P-Early-Media 


[109] 8 





c11 


[109] 8 





c12 


6 


P-Media-Authorization 


[31] 5.1 


c9 


X 


[31] 5.1 


n/a 


n/a 


9 


Rseq 


[27] 7.1 


m 


m 


[27] 7.1 


i 


i 


11 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c9: 


IF A.1 62/26 THEN m ELSE n/a - 


- SIP extensions for media authorization. 






c11: 
c12: 
c13: 
c14: 


IF A.1 62/76 THEN m ELSE n/a - - the SIP P-Early-Media private header extension for authorization of early 

media. 

IF A.1 62/76 THEN (IF A.3/2 THEN m ELSE i) ELSE n/a - - P-CSCF, using the information in the P-Early- 
Media header. 

IF A.1 62/75 THEN m ELSE n/a - - the P-Answer-State header extension to the session initiation protocol for 
the open mobile alliance push to talk over cellular. 

IF A.162/75 THEN i ELSE n/a - - the P-Answer-State header extension to the session initiation protocol for 
the open mobile alliance push to talk over cellular. 
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Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A. 164/102 - - Additional for 2xx response 



Table A.209: Supported headers within the INVITE response 



ItGITI 


rieauer 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 




i 


1A 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 




i 


1B 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 




i 


2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


4 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


6 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


7 


P-Answer-State 


[1111 


c13 


c13 


[111] 


c14 


c14 


8 


P-Media-Authorization 


[31] 5.1 


c9 


X 


[31] 5.1 


n/a 


n/a 


9 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


10 


Session-Expires 


[58] 4 


c11 


c11 


[58] 4 


c11 


c11 


13 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 



cl : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A. 162/1 4 THEN m ELSE i - - tlie requirement to be able to insert itself in the subsequent transactions in a 



dialog. 

c9: IF A.I 62/26 THEN m ELSE n/a - - SIP extensions for media authorization, 

cl 1 : IF A.I 62/52 THEN m ELSE n/a - - the SIP session timer. 

cl 3: IF A.I 62/75 THEN m ELSE n/a - - the P-Answer-State header extension to the session initiation protocol for 

the open mobile alliance push to talk over cellular, 
cl 4: IF A.I 62/75 THEN i ELSE n/a - - the P-Answer-State header extension to the session initiation protocol for 
the open mobile alliance push to talk over cellular. 



Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A.164/103 OR A.164/104 OR A.164/105 OR A.164/106 - - Additional for 3xx - 6xx response 



Table A.209A: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A.164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 



Table A.210: Supported headers within the INVITE response 



Item 


IHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


cl 


cl 


cl: 


IF A.162/19E THEN m ELSE i - - 


deleting Contact headers 
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Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.21 1 : Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


15 


www-Authenticate 


[26] 20.44 







[26] 20.44 








Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/17 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/50 OR A. 164/51 - - Additional for 404 (Not 
Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 (Busy Here), 500 (Internal Server Error), 
600 (Busy Everywhere), 603 (DecUne) response 

Table A.21 2: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


8 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 


12 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



Table A.21 3: Void 

Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.21 4: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


11 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.21 5: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 
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Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 



Table A.216: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


10 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.162/18 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 



Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/28 OR A. 164/41 A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.216A: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


c1: 


IF A.1 62/47 THEN m ELSE n/a - 


- security mechanism agreement for the session initiation protocol. 



Prerequisite A. 16/9 - - INVITE response 

Prerequisite: A.164/28A - - Additional for 422 (Session Interval Too Small) response 

Table A.216B: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Min-SE 


[58] 5 


c1 


c1 


[58] 5 


c1 


c1 


c1: 


IF A.162/52 THEN m ELSE n/a - 


- the SIP session timer. 











Table A.217: Void 
Table A.217A: Void 

Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A.164/45 - - 503 (Service Unavailable) 

Table A.217B: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


8 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 
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Table A.218: Void 

A.2.2.4.7A MESSAGE method 

Prerequisite A.163/9A - - MESSAGE request 



Table A.218A: Supported headers within the MESSAGE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept-Contact 


[56B1 9.2 


c28 


c28 


[568] 9.2 


c28 


c29 


1A 


Allow 


[26] 20.5 


m 


m 


[50] 1 


i 


i 


2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


1 


i 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


5 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c4 


c4 


6 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


i 


7 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


8 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


1 


i 


9 


Content-Lengtli 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


10 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


1 


i 


11 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


12 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


13 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


1 


i 


14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


14A 


Geolocation 


[89] 3.2 


c36 


c36 


[89] 3.2 


c37 


c37 


14B 


History-Info 


[66] 4.1 


c32 


c32 


[66] 4.1 


c32 


c32 


15 


In-Reply-To 


[26] 20.21 


m 


m 


[50] 10 


1 


1 


16 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


17 


MIME-Verslon 


[26] 20.24 


m 


m 


[26] 20.24 


1 


1 


18 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


18A 


P-Access-Networl<-lnfo 


[52] 4.4 


c23 


c23 


[52] 4.4 


c24 


c24 


18B 


P-Asserted-ldentity 


[34] 9.1 


c10 


c10 


[34] 9.1 


c11 


c11 


18C 


P-Asserted-Service 


[121] 4.1 


c40 


c40 


[121] 4.1 


c41 


c41 


18D 


P-Called-Party-ID 


[52] 4.2 


c14 


c14 


[52] 4.2 


c15 


c16 


18E 


P-Cfiarging-Function- 
Addresses 


[52] 4.5 


c21 


c21 


[52] 4.5 


c22 


c22 


18F 


P-Charglng-Vector 


[52] 4.6 


c19 


c19 


[52] 4.6 


c20 


c20 


18G 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c9 


c9 


18H 


P-Preferred-Service 


[121] 4.2 


X 


X 


[121] 4.2 


c39 


c39 


181 


P-Profile-Key 


[9715 


c34 


c34 


[9715 


c35 


c35 


18J 


P-User-Database 


[82] 4 


c33 


c33 


[82] 4 


c33 


c33 


18K 


P-Vislted-Networl<-ID 


[52] 4.3 


c17 


n/a 


[52] 4.3 


c18 


n/a 


19 


Priority 


[26] 20.26 


m 


m 


[26] 20.26 


1 


i 


19A 


Privacy 


[33] 4.2 


c12 


c12 


[33] 4.2 


c13 


c13 


20 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c8 


c8 


21 


Proxy- Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


21A 


Reason 


[34A] 2 


c26 


c26 


[34A] 2 


c27 


c27 


22 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


22A 


Referred-By 


[59] 3 


c30 


c30 


[59] 3 


c31 


c31 


23 


Reject-Contact 


[56B] 9.2 


c28 


c28 


[56B] 9.2 


c28 


c29 


23A 


Reply-To 


[26] 20.31 


m 


m 


[26] 20.31 


1 


i 


23B 


Request-Disposition 


[56B] 9.1 


c28 


c28 


[56B] 9.1 


c28 


c28 


24 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


25 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


25A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c25 


c25 


25B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c25 


c25 


26 


Subject 


[26] 20.36 


m 


m 


[26] 20.36 






27 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


28 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 






29 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


30 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 






31 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE 1 - - insertion of date in requests and responses. 

c3; IF A.162/19A OR A.162/19B THEN m ELSE 1 - - reading, adding or concatenating the Organization header. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE 1 - - reading, adding or concatenating the Call-Info header. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A. 1 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 

c8: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c9: IF A.1 62/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c10: IF A.1 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 
within trusted networks. 

c1 1 : IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c12: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c13: IF A.1 62/31 D OR A.1 62/31 G THEN m ELSE IF A.1 62/31 C THEN 1 ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c14: IF A.162/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 
c15: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c16: IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND (A.3/3 OR A.3/9A) THEN i ELSE n/a - - the P- 

Cal led- Party- ID header extension and P-CSCF or (l-CSCF or IBCF (THIG). 
c1 7: IF A.1 62/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c1 8: IF A.1 62/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 
request or response. 

c19: IF A.1 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c20: IF A.1 62/46 THEN m ELSE IF A.1 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Gharging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c21 : IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c22: IF A.162/44A THEN m ELSE IF A.1 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c23: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c24: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c25: IF A. 4/37 A. 162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c26: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c27: IF A. 162/48 THEN 1 ELSE n/a - - the Reason header field for the session initiation protocol. 

c28: IF A.1 62/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c29: IF A.1 62/50 AND A.4/3 THEN m ELSE IF A.1 62/50 AND NOT A.4/3 THEN i ELSE n/a - - caller preferences 

for the session initiation protocol, and S-CSCF. 
c30: IF A.162/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 
c31: IF A.162/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c32: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 
information. 

c33: IF A.1 62/60 THEN m ELSE n/a - - the P-User-Database private header extension. 
c34: IF A.1 62/66A THEN m ELSE n/a - - making the first query to the database in order to populate the P- 
Profile-Key header. 

c35: IF A.162/66B THEN m ELSE n/a - - using the information in the P-Profile-Key header. 
c36: IF A.162/70 THEN m ELSE n/a - - SIP location conveyance. 

c37: IF A.162/70A THEN m ELSE IF A.162/70B THEN i ELSE n/a - - addition or modification of location in a SIP 

method, passes on locations in SIP method without modification. 
c39: IF A.1 62/84A THEN m ELSE n/a - - act as authentication entity within the trust domain for asserted service. 
c40: IF A.1 62/84 THEN m ELSE n/a - - identification of communication services in the session initiation protocol. 
c41: IF A.1 62/84 OR A.162/30B THEN m ELSE i - - identification of communication services in the session 

initiation protocol or subsequent entity within trust network that can route outside the trust network. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 

SUBSCRIBE and NOTIFY. 
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Table A.218B: Void 

Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A.164/1 - - Additional for 100 (Trying) response 



Table A.218BA: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF (A.162/9 AND A.162/5) OR A.1 62/4 THEN m ELSE n/a 


- - stateful proxy behaviour that inserts date, or 


c2: 


stateless proxies. 

IF A.1 62/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A.163/9B - - MESSAGE response for all remaining status-codes 



Table A.218C: Supported headers within the lUlESSAGE response 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


II 1 n\ 

Gall-ID 


[26J 20.8 


m 


m 


ro/^1 OA A 

[26J 20.8 


m 


m 


2 


Oall-lnfo 


[26] 20.9 


m 


m 


[26] 20.9 


c3 


c3 


3 


Content-Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


i 


4 


Content-Encoding 


[26] 20.12 


m 


m 


rOAl OA H o 

[26] 20.1 2 


i 


i 


5 


Content-Language 


[26] 20.13 


m 


m 


rOAl OA -i o 

[26] 20.1 3 


i 


i 


6 


Content-Length 


[26J 20.1 4 


m 


m 


rOAl OA H A 

[26J 20.14 


m 


m 


7 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


8 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


9 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c1 


c1 


9A 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


10 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10A 


Geolocation 


[89] 3.2 


c17 


c17 


[89] 3.2 


c18 


c18 


10B 


History-Info 


[66] 4.1 


c16 


c16 


[66] 4.1 


c16 


c16 


1 1 


IVIIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


12 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


12A 


P-Access-Networl<- 1 nfo 


[52] 4.4 


c13 


c13 


[52] 4.4 


c14 


c14 


12B 


P-Asserted-ldentity 


[34] 9.1 


c5 


c5 


[34] 9.1 


c6 


c6 


12C 


P-Ciiarging-Function- 
Addresses 


[52] 4.5 


c11 


c11 


[52] 4.5 


c12 


c12 


1 on 


r-onarging- vecTor 


[52] 4.6 


c9 


n/a 


[52] 4.6 


c10 


n/a 


12E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c4 


n/a 


12F 


Privacy 


[33] 4.2 


c7 


c7 


[33] 4.2 


c8 


c8 


12G 


Reply-To 


[26] 20.31 


m 


m 


[26] 20.31 


i 


i 


12H 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c15 


c15 


13 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


14 


Timestamp 


[26] 20.38 


i 


i 


[26] 20.38 


i 


i 


15 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


16 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


17 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


18 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 
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c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c3; IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c4: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c5: IF A.1 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c6: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c7: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c8: IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c9: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

clO: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c1 1 : IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c12: IF A.162/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c13: IF A.I 62/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c14: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c15: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 
the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c16: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 
information. 

c1 7: IF A.I 62/70 THEN m ELSE n/a - - SIP location conveyance. 

c18: IF A.162/70A THEN m ELSE IF A.162/70B THEN i ELSE n/a - - addition or modification of location in a SIP 
method, passes on locations in SIP method without modification. 



Prerequisite A.163/9B - - MESSAGE response 
Prerequisite: A. 164/102 - - Additional for 2xx response 



Table A.218D: Supported headers within the lUlESSAGE response 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


2 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


1 




4 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 




c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.I 62/1 5 THEN o ELSE 1 - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 
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Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A.164/103 OR A.164/104 OR A.164/105 OR A.164/106 - - Additional for 3xx - 6xx response 



Table A.218DA: Supported headers within the lUlESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A.164/103 OR A.164/35 - - Additional for 3xx or 485 (Ambiguous) response 



Table A.218E: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


cl 


c1: 


IF A.I 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.218F: Supported headers within the lUIESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/17 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/42 OR A. 164/45 OR A. 164/50 OR 
A.164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (DecUne) response 

Table A.218G: Supported headers within the lUIESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 



Table A.218H: Void 

Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 



Table A.218I: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


3 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 
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Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) 



Table A.218J: Supported headers within the lUlESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 

Table A.218K: Supported headers within the iUIESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 



Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/28 OR A.164/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.218L: Supported headers within the IUIESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


3 


Security-Server 


[48] 2 


Cl 


cl 


[48] 2 


n/a 


n/a 


c1: 


IF A.I 62/47 THEN m ELSE n/a 


- - security mechanism agreement for the session initiation protocol. 
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Table A.218M: Void 
Table A.218N: Void 

A.2.2.4.8 NOTIFY method 

Prerequisite A. 163/10 - - NOTIFY request 



Table A.219: Supported headers within the NOTIFY request 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[261 20.1 


m 


m 


[26] 20.1 


i 


i 


1A 


Accept-Contact 


[56B1 9.2 


c21 


c21 


[56B] 9.2 


c22 


c22 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 


i 


3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6A 


Gall-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c28 


c28 


6B 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


7 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


i 


8 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


9 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


14 


Event 


[28] 7.2.1 


m 


m 


[28] 7.2.1 


m 


m 


15 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15A 


Geolocation 


[89] 3.2 


c26 


c26 


[89] 3.2 


c27 


c27 


15B 


History-Info 


[66] 4.1 


c25 


c25 


[66] 4.1 


c25 


c25 


16 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


17 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


17A 


P-Access-Networl<- 1 nfo 


[52] 4.4 


c16 


c16 


[52] 4.4 


c17 


c17 


17B 


P-Asserted-ldentity 


[34] 9.1 


c8 


c8 


[34] 9.1 


c9 


c9 


17C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c14 


c14 


[52] 4.5 


c15 


c15 


17D 


P-Charging-Vector 


[52] 4.6 


c12 


n/a 


[52] 4.6 


c13 


n/a 


17E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c3 


n/a 


17F 


Privacy 


[33] 4.2 


c10 


clO 


[33] 4.2 


c11 


c11 


18 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


19 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


19A 


Reason 


[34A] 2 


c19 


c19 


[34A] 2 


c20 


c20 


20 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


20A 


Referred-By 


[59] 3 


c23 


c23 


[59] 3 


c24 


c24 


20B 


Reject-Contact 


[56B] 9.2 


c21 


c21 


[56B] 9.2 


c22 


c22 


20C 


Request-Disposition 


[56B] 9.1 


c21 


c21 


[56B] 9.1 


c22 


c22 


21 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


22 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


22A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


22B 


Security- Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


23 


Subscription-State 


[28] 8.2.3 


m 


m 


[28] 8.2.3 






24 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


25 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 






26 


To 


[26] 20.39 


nn 


m 


[26] 20.39 


m 


m 


27 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 






28 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


29 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 
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c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE 1 - - insertion of date in requests and responses. 

c3; IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted Identity. 

c4: IF A.162/8A THEN m ELSE I - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE I - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c6: IF A. 1 62/1 6 THEN m ELSE I - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14THEN (IF A.162/22 OR A.1 62/27 THEN m ELSE o) ELSE i - - the requirement to be able to 

insert itself in the subsequent transactions in a dialog or (the REFER method or SIP specific event 
notification). 

c8: IF A.1 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted Identity 

within trusted networks. 

c9: IF A.162/30A or A.162/30B THEN m ELSE I - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c1 0: IF A.1 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c11: IF A.1 62/31 D OR A.1 62/31 G THEN m ELSE IF A.1 62/31 C THEN 1 ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c12: IF A.1 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c13: IF A.1 62/46 THEN m ELSE IF A.1 62/45 THEN i ELSE n/a -- adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c14: IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Functlon-Addresses header extension. 

c1 5: IF A.1 62/44A THEN m ELSE IF A.1 62/44 THEN I ELSE n/a - - adding, deleting or reading the P-Charglng- 

Functlon-Addresses header before proxying the request or response, or the P-Charglng-Functlon- 

Addresses header extension. 

c16: IF A.1 62/43 THEN x ELSE IF A.1 62/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c17: IF A.162/43 THEN m ELSE IF A.162/41 THEN 1 ELSE n/a - - act as subsequent entity within trust network 
for access network Information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c1 8: IF A. '1 /37 A.1 62/47 THEN m ELSE n/a - - security mechanism agreement for the session Initiation protocol. 

c19: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c20: IF A. 162/48 THEN 1 ELSE n/a - - the Reason header field for the session initiation protocol. 

c21 : IF A.162/50 THEN m ELSE n/a - - caller preferences for the session Initiation protocol. 

c22: IF A.1 62/50 THEN i ELSE n/a - - caller preferences for the session Initiation protocol. 

c23: IF A.1 62/53 THEN I ELSE n/a - - the SIP Referred-By mechanism. 

c24: IF A.1 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c25: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 
information. 

c26: IF A.162/70 THEN m ELSE n/a - - SIP location conveyance. 

c27: IF A.162/70A THEN m ELSE IF A.162/70B THEN I ELSE n/a - - addition or modification of location In a SIP 

method, passes on locations in SIP method without modification. 
c28: IF A.1 62/1 9C OR A.1 62/1 9D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 



NOTE: c1 refers to the UA role major capability as this Is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/10 - - NOTIFY request 

Table A.220: Supported message bodies within the NOTIFY request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


sipfrag 


[3712 


m 


m 


[3712 


i 


1 
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Prerequisite A. 163/11 - - NOTIFY response 

Prerequisite: A.164/1 - - Additional for 100 (Trying) response 



Table A.220A: Supported headers within the NOTIFY response 



llclll 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


g2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a 


- - stateful proxy behaviour that inserts date, or 


c2: 


stateless proxies. 

IF A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/11 - - NOTIFY response for all remaining status-codes 



Table A.221 : Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


uali-IU 


[26J 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


i 


3 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


7 


Cseq 


[26] 20.1 6 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


Geolocation 


[89] 3.2 


c14 


c14 


[89] 3.2 


c15 


c15 


10 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


10A 


P-Access-Network-lnfo 


[52] 4.4 


c11 


oil 


[52] 4.4 


c12 


c12 


10B 


P-Asserted-ldentity 


[34] 9.1 


c3 


c3 


[34] 9.1 


c4 


c4 


10C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c9 


c9 


[52] 4.5 


clO 


clO 


10D 


P-Charging-Vector 


[52] 4.6 


c7 


n/a 


[52] 4.6 


c8 


n/a 


10E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c2 


n/a 


10F 


Privacy 


[33] 4.2 


c5 


c5 


[33] 4.2 


c6 


c6 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c13 


c13 


10H 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



cl : IF A.I 62/9 THEN m ELSE i - - Insertion of date in requests and responses. 

c2: IF A.I 62/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c3: IF A. 162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 



c4: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c5: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c6: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 THEN 1 ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "Id" or passing on of the Privacy header transparently. 
c7: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c8: IF A.162/46 THEN m ELSE IF A.162/45 THEN 1 ELSE n/a - - adding, deleting, reading or modifying the P- 

Charglng-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c9: IF A.I 62/44 THEN m ELSE n/a - - the P-Charglng-Function-Addresses header extension. 

cl 0: IF A.I 62/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c11: IF A. 162/43 THEN x ELSE IF A.I 62/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c12: IF A.162/43 THEN m ELSE IF A.162/41 THEN 1 ELSE n/a - - act as subsequent entity within trust network 
for access network Information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c13: IF A.162/11 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 
the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c14: IF A.I 62/70 THEN m ELSE n/a - - SIP location conveyance. 

cl 5: IF A.I 62/70A THEN m ELSE IF A.I 62/70B THEN i ELSE n/a - - addition or modification of location in a SIP 
method, passes on locations in SIP method without modification. 



Prerequisite A. 163/11 - - NOTIFY response 
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Prerequisite: A. 164/102 - - Additional for 2xx response 



Table A.222: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


c1 


1 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


1A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


2 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 



c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.1 62/1 5 THEN m ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/11 - - NOTIFY response 

Prerequisite: A.164/103 OR A.164/104 OR A.164/105 OR A.164/106 - - Additional for 3xx - 6xx response 



Table A.222A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/11 - - NOTIFY response 
Prerequisite: A.164/103 - - Additional for 3xx response 



Table A.223: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 


Profile 


Ref. 


RFC 


Profile 








Status 


status 




Status 


status 


1 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


cl 


cl 


cl: 


IF A.I 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/11 - - NOTIFY response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.224: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 
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Prerequisite A. 163/11 - - NOTIFY response 

Prerequisite: A. 164/1 7 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/42 OR A. 164/45 OR A. 164/50 OR 
A.164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 



Table A.225: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 



Table A.226: Void 

Prerequisite A. 163/11 - - NOTIFY response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 



Table A.227: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A.164/25 - - Additional for 415 (Unsupported Media Type) response 



Table A.228: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 



Table A.229: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A. 163/11 - - NOTIFY response 

Prerequisite: A. 164/28 OR A. 164/41 A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 



Table A.229A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ret. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security meclianism agreement for the session initiation protocol. 



Table A.230: Void 

Prerequisite A. 163/11 - - NOTIFY response 

Prerequisite: A. 164/35 - - Additional for 485 (Ambigious) response 

Table A.230A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 



Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A. 164/39 - - Additional for 489 (Bad Event) response 



Table A.231 : Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


c1: 


IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 








NOTE: 


c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 
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Table A.232: Void 

A.2.2.4.9 OPTIONS method 

Prerequisite A. 163/12 - - OPTIONS request 



Table A.233: Supported headers within the OPTIONS request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[261 20.1 


m 


m 


[261 20.1 


1 


i 


1A 


Accept-Contact 


[56B] 9.2 


c28 


c28 


[568] 9.2 


c28 


c29 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 


i 


3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c4 


c4 


8 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


9 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


i 


10 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


11 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


12 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


13 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


14 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


15 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


16A 


Geolocation 


[89] 3.2 


c36 


c36 


[89] 3.2 


c37 


c37 


16B 


History-Info 


[66] 4.1 


c32 


c32 


[66] 4.1 


c32 


c32 


17 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


18 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


19 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


19A 


P-Access-Network-lnfo 


[52] 4.4 


c23 


c23 


[52] 4.4 


c24 


c24 


19B 


P-Asserted- Identity 


[34] 9.1 


clO 


clO 


[34] 9.1 


c11 


c11 


19C 


P-Asserted-Service 


[121] 4.1 


c39 


c39 


[121] 4.1 


c40 


c40 


19D 


P-Called-Party-ID 


[52] 4.2 


c14 


c14 


[52] 4.2 


c15 


CIS 


19E 


P-Charging-Function- 
Addresses 


[52] 4.5 


c21 


c21 


[52] 4.5 


c22 


c22 


19F 


P-Charging-Vector 


[52] 4.6 


c19 


c19 


[52] 4.6 


c20 


c20 


19G 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c9 


c9 


19H 


P-Preferred-Service 


[121] 4.2 


X 


X 


[121] 4.2 


c38 


c38 


191 


P-Profile-Key 


[97] 5 


c34 


c34 


[97] 5 


c35 


c35 


19J 


P-User-Database 


[82] 4 


c33 


c33 


[82] 4 


c33 


c33 


19k 


P-Visited-Network-ID 


[52] 4.3 


c17 


n/a 


[52] 4.3 


c18 


n/a 


19L 


Privacy 


[33] 4.2 


c12 


c12 


[33] 4.2 


c13 


c13 


20 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c8 


c8 


21 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


21A 


Reason 


[34A] 2 


c26 


c26 


[34A] 2 


c27 


c27 


22 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


22A 


Referred-By 


[5913 


c30 


c30 


[59] 3 


c31 


c31 


22B 


Reject-Contact 


[56B] 9.2 


c28 


c28 


[56B] 9.2 


c28 


c29 


22C 


Request-Disposition 


[56B] 9.1 


c28 


c28 


[56B] 9.1 


c28 


c28 


23 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


24 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


24A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c25 


c25 


24B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c25 


c25 


25 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


26 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


27 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


28 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


29 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE 1 - - insertion of date in requests and responses. 

c3; IF A.162/19A OR A.162/19B THEN m ELSE 1 - - reading, adding or concatenating the Organization header. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE 1 - - reading, adding or concatenating the Call-Info header. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A. 1 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 

c8: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c9: IF A.1 62/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c10: IF A.1 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 
within trusted networks. 

c1 1 : IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c12: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c13: IF A.1 62/31 D OR A.1 62/31 G THEN m ELSE IF A.1 62/31 C THEN 1 ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c14: IF A.162/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 
c15: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c16: IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND (A.3/3 OR A.3/9A) THEN i ELSE n/a - - the P- 

Cal led- Party- ID header extension and P-CSCF or (l-CSCF or IBCF (THIG)). 
c1 7: IF A.1 62/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c1 8: IF A.1 62/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 
request or response. 

c19: IF A.1 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c20: IF A.1 62/46 THEN m ELSE IF A.1 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Gharging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c21 : IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c22: IF A.162/44A THEN m ELSE IF A.1 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c23: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c24: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c25: IF A. 4/37 A. 162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c26: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c27: IF A. 162/48 THEN 1 ELSE n/a - - the Reason header field for the session initiation protocol. 

c28: IF A.1 62/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c29: IF A.1 62/50 AND A.4/3 THEN m ELSE IF A.1 62/50 AND NOT A.4/3 THEN i ELSE n/a - - caller preferences 

for the session initiation protocol, and S-CSCF. 
c30: IF A.162/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 
c31: IF A.162/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c32: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 
information. 

c33: IF A.1 62/60 THEN m ELSE n/a - - the P-User-Database private header extension. 
c34: IF A.1 62/66A THEN m ELSE n/a - - making the first query to the database in order to populate the P- 
Profile-Key header. 

c35: IF A.162/66B THEN m ELSE n/a - - using the information in the P-Profile-Key header. 
c36: IF A.162/70 THEN m ELSE n/a - - SIP location conveyance. 

c37: IF A.162/70A THEN m ELSE IF A.162/70B THEN i ELSE n/a - - addition or modification of location in a SIP 

method, passes on locations in SIP method without modification. 
c38: IF A.1 62/84A THEN m ELSE n/a - - act as authentication entity within the trust domain for asserted service. 
c39: IF A.1 62/84 THEN m ELSE n/a - - identification of communication services in the session initiation protocol. 
c40: IF A.1 62/84 OR A.162/30B THEN m ELSE i - - identification of communication services in the session 

initiation protocol or subsequent entity within trust network that can route outside the trust network. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 

SUBSCRIBE and NOTIFY. 
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Table A.234: Void 
Table A.235: Void 

Prerequisite A. 163/1 3 - - OPTIONS response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 



Table A.235A: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ret. 


RFC 
Status 


Profile 
status 


Ret. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Gseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a 


- - stateful proxy behaviour that inserts date, or 


c2: 


stateless proxies. 

IF A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/13 - - OPTIONS response for all remaining status-codes 



Table A.236: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


A llmAi 

Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Gall-ID 


[26J 20.8 


m 


m 


[26J 20.8 


m 


m 


H A 

1 A 


1 1 1 L^f ^ 

Oall-lnfo 


[26] 20.9 


m 


m 


[26] 20.9 


c3 


c3 


2 


Content-Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


i 


3 


Content-Encoding 


[26] 20.12 


m 


m 


TAAI AA H A 

[26] 20.1 2 


i 


i 


4 


Content-Language 


[26] 20.13 


m 


m 


FAAI AA -i A 

[26] 20.1 3 


i 


i 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.1 5 


m 


m 


[26] 20.15 


i 


i 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


Geolocation 


[89] 3.2 


c17 


c17 


[89] 3.2 


c18 


c18 


9B 


History-Info 


[66] 4.1 


c16 


c16 


[66] 4.1 


c16 


c16 


10 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


1 1 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


1 1 A 


P-Access-Networl<-lnfo 


[52] 4.4 


c13 


c13 


[52] 4.4 


c14 


c14 


1 1 B 


P-Asserted- Identity 


[34] 9.1 


c5 


c5 


[34] 9.1 


c6 


c6 


lie 


P-Cliarging-Function- 

Auuresses 


[od\ 4.0 


Cl 1 


C1 1 


[Od\ 4.0 


Old 




11D 


P-Charging-Vector 


[52] 4.6 


c9 


c9 


[52] 4.6 


clO 


ClO 


11E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c4 


n/a 


11F 


Privacy 


[33] 4.2 


c7 


c7 


[33] 4.2 


c8 


c8 


11G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c15 


c15 


11H 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


12 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 
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c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c3; IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c4: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c5: IF A.1 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c6: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c7: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c8: IF A.162/31D OR A.1 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c9: IF A.1 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

clO: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c1 1 : IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c12: IF A.162/44A THEN m ELSE IF A.1 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c13: IF A.1 62/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c14: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c15: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 
the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c16: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 
information. 

c1 7: IF A.1 62/70 THEN m ELSE n/a - - SIP location conveyance. 

c18: IF A.162/70A THEN m ELSE IF A.162/70B THEN i ELSE n/a - - addition or modification of location in a SIP 
method, passes on locations in SIP method without modification. 



Prerequisite A. 163/13 - - OPTIONS response 
Prerequisite: A. 164/102 - - Additional for 2xx response 



Table A.237: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


1 


i 


1A 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


1 


i 


IB 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


1 


1 


2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


1 


i 


5 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


1 


1 


9 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


12 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.1 62/1 5 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 
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Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A.164/103 OR A.164/104 OR A.164/105 OR A.164/106 - - Additional for 3xx - 6xx response 



Table A.237A: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A.164/103 OR A.164/35 - - Additional for 3xx or 485 (Ambiguous) response 



Table A.238: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


cl 


c1: 


IF A.I 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.239: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/17 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/42 OR A. 164/45 OR A. 164/50 OR 
A.164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (DecUne) response 

Table A.240: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 



Table A.241 : Void 

Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 



Table A.242: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 
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Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 



Table A.243: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/1 3 - - OPTIONS response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 

Table A.244: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


7 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 



Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/28 OR A.164/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.244A: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


3 


Security-Server 


[48] 2 


Cl 


cl 


[48] 2 


n/a 


n/a 


c1: 


IF A.I 62/47 THEN m ELSE n/a 


- - security mechanism agreement for the session initiation protocol. 
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Table A.245: Void 
Table A.246: Void 

A.2.2.4.11 REFER method 

Prerequisite A. 163/16 - - REFER request 



Table A.261 : Supported headers within the REFER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 


OB 


Accept-Contact 


[56B1 9.2 


c27 


c27 


[56B] 9.2 


c27 


c28 


OC 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


j 


1 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 


i 


1A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


5 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


5A 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 




5B 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 




5C 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


j 


6 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


7 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


8 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


9 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


10 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


11 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


11A 


Geolocation 


[89] 3.2 


c35 


c35 


[89] 3.2 


c36 


c36 


11B 


History-Info 


[66] 4.1 


c31 


c31 


[66] 4.1 


c31 


c31 


12 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


13 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


14 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


14A 


P-Access-Networl<- 1 nfo 


[52] 4.4 


c22 


c22 


[52] 4.4 


c23 


c23 


14B 


P-Asserted-ldentity 


[34] 9.1 


c9 


c9 


[34] 9.1 


clO 


c10 


14C 


P-Asserted-Service 


[121] 4.1 


c38 


c38 


[121] 4.1 


c39 


c39 


14D 


P-Called-Party-ID 


[52] 4.2 


c13 


c13 


[52] 4.2 


c14 


c15 


14E 


P-Charging-Function- 

Addresses 


[52] 4.5 


c20 


c20 


[52] 4.5 


c21 


c21 


14F 


P-Charging-Vector 


[52] 4.6 


c18 


c18 


[52] 4.6 


c19 


c19 


14G 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c8 


c8 


14H 


P-Preferred-Service 


[121] 4.2 


X 


X 


[121] 4.2 


c37 


c37 


141 


P-Profile-Key 


[97] 5 


c33 


c33 


[97] 5 


c34 


c34 


14J 


P-User-Database 


[82] 4 


c32 


c32 


[82] 4 


c32 


c32 


14K 


P-Visited-Networl<-ID 


[52] 4.3 


c16 


n/a 


[52] 4.3 


c17 


n/a 


14L 


Privacy 


[33] 4.2 


c11 


c11 


[33] 4.2 


c12 


c12 


15 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


16 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


16A 


Reason 


[34A] 2 


c25 


c25 


[34A] 2 


c26 


c26 


17 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


18 


Refer-To 


[36] 3 


c3 


c3 


[36] 3 


c4 


c4 


ISA 


Referred-By 


[59] 3 


c29 


c29 


[59] 3 


c30 


c30 


18B 


Reject-Contact 


[56B] 9.2 


c27 


c27 


[568] 9.2 


c27 


c28 


18C 


Request-Disposition 


[56B] 9.1 


c27 


c27 


[56B] 9.1 


c27 


c27 


19 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


20 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


20A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c24 


c24 


20B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c24 


c24 


21 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


22 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


23 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


24 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 
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25 I Via I [26] 20.42 | m Lm | [26] 20.42 | m Lm 

c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A. 162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c4: IF A.162/8A THEN m ELSE 1 - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c6: IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.1 62/1 4 THEN m ELSE i - - the requirement to be able to insert itself in the subsequent transactions in 

a dialog. 

c8: IF A.I 62/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 
c9: IF A.I 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 
within trusted networks. 

clO: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c1 1 : IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c12: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c13: IF A.I 62/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 
c14: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c15: IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND (A.3/3 OR A.3/9A) THEN i ELSE n/a - - the P- 

Cal led- Party- ID header extension and P-CSCF or (l-CSCF or IBCF (THIG). 
c1 6: IF A.I 62/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c1 7: IF A.I 62/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 
request or response. 

c18: IF A. 162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c19: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c20: IF A.I 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c21: IF A.162/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c22: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c23: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c24: IF A. 4/37 A. 1 62/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c25: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c26: IF A.162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

c27: IF A.I 62/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c28: IF A.I 62/50 AND A.4/3 THEN m ELSE IF A.I 62/50 AND NOT A.4/3 THEN i ELSE n/a - - caller preferences 

for the session initiation protocol, and S-CSCF. 
c29: IF A.162/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 
c30: IF A.162/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c31 : IF A.I 62/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 
information. 

c32: IF A.I 62/60 THEN m ELSE n/a - - the P-User-Database private header extension. 
c33: IF A.I 62/66A THEN m ELSE n/a - - making the first query to the database in order to populate the P- 
Profile-Key header. 

c34: IF A.162/66B THEN m ELSE n/a - - using the information in the P-Profile-Key header. 
c35: IF A.I 62/70 THEN m ELSE n/a - - SIP location conveyance. 

c36: IF A.I 62/70A THEN m ELSE IF A.I 62/70B THEN i ELSE n/a - - addition or modification of location in a SIP 

method, passes on locations in SIP method without modification. 
c37: IF A.I 62/84A THEN m ELSE n/a - - act as authentication entity within the trust domain for asserted service. 
c38: IF A.I 62/84 THEN m ELSE n/a - - identification of communication services in the session initiation protocol. 
c39: IF A. 162/84 OR A.162/30B THEN m ELSE i - - identification of communication services in the session 

initiation protocol or subsequent entity within trust network that can route outside the trust network. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 

SUBSCRIBE and NOTIFY. 
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Table A.262: Void 
Table A.263: Void 

Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 



Table A.263A: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ret. 


RFC 
Status 


Profile 
status 


Ret. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Gseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a 


- - stateful proxy behaviour that inserts date, or 


c2: 


stateless proxies. 

IF A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/17 - - REFER response for all remaining status-codes 



Table A.264: Supported headers within the REFER response 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


ror*i AA c 

[26] 20.5 


i 


i 


1 


uali-IU 


[26J 20.8 


m 


m 


FA/^l AA A 

[26J 20.8 


m 


m 




Contact 


[26] 20.1 


m 


m 


[26] 20.10 


i 


i 


1 B 


Content-Disposition 


[26] 20. 11 


m 


m 


[26] 20.1 1 


i 


i 


2 


Content-Encoding 


[26] 20.12 


m 


m 


TAAI AA H A 

[26] 20.1 2 


i 


i 


3 


Content-Language 


[26] 20.13 


m 


m 


FAAI AA A A 

[26] 20.1 3 


i 


i 


4 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


5 


Content-Type 


[26] 20.1 5 


m 


m 


[26] 20.15 


i 


i 


6 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


7 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


cl 


cl 


8 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


8A 


Geolocation 


[89] 3.2 


c16 


c16 


[89] 3.2 


c17 


c17 


SB 


History-Info 


[66] 4.1 


c15 


c15 


[66] 4.1 


c15 


c15 


9 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


10 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


10A 


P-Access-Networl<-lnfo 


[52] 4.4 


c12 


c12 


[52] 4.4 


c13 


c13 


10B 


P-Asserted- Identity 


[34] 9.1 


c4 


c4 


[34] 9.1 


c5 


c5 


IOC 


P-Cliarging-Function- 

Auuresses 


[0<ij 4.0 


Cl U 


C1 U 


[Od\ 4.0 


Cl 1 


Cl 1 


10D 


P-Charging-Vector 


[52] 4.6 


c8 


c8 


[52] 4.6 


c9 


c9 


10E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c3 


n/a 


10F 


Privacy 


[33] 4.2 


c6 


c6 


[33] 4.2 


c7 


c7 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c14 


c14 


10H 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 
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c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c3; IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c4: IF A. 162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c5: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c6: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c7: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c8; IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c9: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

clO: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

oil: IF A.162/44ATHEN m ELSE IF A. 162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c12: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network Information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c13: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c14: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 
the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c1 5: IF A.I 62/57 THEN m ELSE n/a - - an extension to the session Initiation protocol for request history 

information. 

c16: IF A.162/70 THEN m ELSE n/a - - SIP location conveyance. 

c1 7: IF A.I 62/70A THEN m ELSE IF A.I 62/70B THEN 1 ELSE n/a - - addition or modification of location in a SIP 
method, passes on locations In SIP method without modification. 



Prerequisite A. 163/17 - - REFER response 
Prerequisite: A. 164/102 - - Additional for 2xx response 



Table A.265: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


2 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


5 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1 : IF A.4/20 THEN m ELSE 1 - - SIP specific event notification extension. 

c3: IF A.I 62/1 5 THEN m ELSE 1 - - the requirement to be able to use separate URIs In the upstream direction 
and downstream direction when record routelng. 
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Prerequisite A. 163/17 - - REFER response 

Prerequisite: A.164/103 OR A.164/104 OR A.164/105 OR A.164/106 - - Additional for 3xx - 6xx response 



Table A.265A: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


i 



Table A.266: Void 

Prerequisite A. 163/1 7 - - REFER response 

Prerequisite: A.164/8 OR A.164/9 OR A.164/10 OR A.164/1 1 OR A.164/12 - - Additional for 401 (Unauthorized) 
response 

Table A.267: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

status 


Profile 

status 


Ref. 


RFC 

status 


Profile 

status 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/17 - - REFER response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A.164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (DecUne) response 



Table A.268: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


1 



Table A.269: Void 

Prerequisite A. 163/1 7 - - REFER response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.270: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 







[26] 20.27 







8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


1 
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Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 



Table A.271 : Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 



Table A.272: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


8 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 



Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/28 OR A.164/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 



Table A.272A: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


3 


Security-Server 


[48] 2 


Cl 


cl 


[48] 2 


n/a 


n/a 


c1: 


IF A.I 62/47 THEN m ELSE n/a 


- - security mechanism agreement for the session initiation protocol. 
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Table A.273: Void 
Table A.274: Void 

A.2.2.4.12 REGISTER method 

Prerequisite A. 163/18 - - REGISTER request 



Table A.275: Supported headers within the REGISTER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


j 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


j 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 


j 


3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


j 


4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7, 
[49] 


m 


m 


[26] 20.7, 
[491 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c2 


c2 


8 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


j 


9 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


j 


10 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


j 


11 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


j 


12 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


13 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


14 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


15 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


m 


m 


16 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


17 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


17A 


Geolocation 


[89] 3.2 


c26 


c26 


[89] 3.2 


c27 


c27 


17B 


History-Info 


[66] 4.1 


c24 


c24 


[66] 4,1 


c24 


c24 


18 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


19 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


20 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


20A 


P-Access-Networi<- 1 nfo 


[52] 4.4 


c16 


c16 


[52] 4.4 


c17 


c17 


20B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c14 


c14 


[52] 4.5 


c15 


c15 


20C 


P-Charging-Vector 


[52] 4.6 


c12 


c12 


[52] 4.6 


c13 


c13 


20D 


P-User-Database 


[82] 4 


c25 


c25 


[82] 4 


n/a 


n/a 


20E 


P-Visited-Network-ID 


[52] 4.3 


clO 


clO 


[52] 4.3 


c11 


c11 


20F 


Path 


[35] 4.2 


c6 


c6 


[35] 4.2 


c6 


c6 


20G 


Privacy 


[33] 4.2 


c8 


c8 


[33] 4.2 


c9 


c9 


21 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c7 


c7 


22 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


22A 


Reason 


[34A] 2 


c19 


c19 


[34A] 2 


c20 


c20 


22B 


Referred-By 


[59] 3 


c22 


c22 


[59] 3 


c23 


c23 


22C 


Request-Disposition 


[56B] 9.1 


c21 


c21 


[56B] 9.1 


c21 


c21 


23 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c4 


c4 


24 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


24A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


24B 


Security- Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


25 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c5 


c5 


26 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


27 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


28 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


29 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c3; IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c4: IF A.162/1 1 OR A.1 62/1 2 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c5: IF A.1 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c6: IF A.1 62/29 THEN m ELSE n/a - - PATH header support. 

c7: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c8: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c9: IFA.162/31DORA.162/31GTHEN m ELSE IF A.1 62/31 C THEN i ELSE n/a -- application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c1 0: IF A.1 62/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c1 1 : IF A.1 62/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 

request or response. 

c12: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c13: IF A.1 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c14: IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c15: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c16: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c17: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c18: IF At4/3? A. 162/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c1 9: IF A.1 62/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c20: IF A.1 62/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

c21 : IF A.1 62/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c22: IF A.1 62/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 

c23: IF A.1 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c24: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 
information. 

c25: IF A.1 62/60 THEN m ELSE n/a - - the P-User-Database private header extension. 
c26: IF A.1 62/70 THEN m ELSE n/a - - SIP location conveyance. 

c27: IF A.162/70A THEN m ELSE IF A.162/70B THEN i ELSE n/a - - addition or modification of location in a SIP 

method, passes on locations in SIP method without modification. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 
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Table A.276: Void 
Table A.277: Void 

Prerequisite A. 163/1 9 - - REGISTER response 

Prerequisite: A. 164/1 - - Additional for 100 (Trying) response 



Table A.277A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ret. 


RFC 
Status 


Profile 
status 


Ret. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Gseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF (A.162/9 AND A.162/5) OR A.162/4 THEN m ELSE n/a 


- - stateful proxy behaviour that inserts date, or 


c2: 


stateless proxies. 

IF A.162/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/19 - - REGISTER response for all remaining status-codes 



Table A.278: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


A llmAi 

Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Gall-ID 


[26J 20.8 


m 


m 


[26J 20.8 


m 


m 


H A 

1 A 


1 1 1 L^f ^ 

Oall-lnfo 


[26] 20.9 


m 


m 


[26] 20.9 


c2 


c2 


2 


Content-Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


i 


3 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.1 2 


i 


i 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.1 5 


m 


m 


[26] 20.15 


i 


i 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


Geolocation 


[89] 3.2 


c13 


c13 


[89] 3.2 


c14 


c14 


9B 


History-Info 


[66] 4.1 


c12 


c12 


[66] 4.1 


c12 


c12 


10 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


1 1 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c1 


c1 


1 1 A 


P-Access-Network-lnfo 


[52] 4.4 


c9 


c9 


[52] 4.4 


c10 


c10 


1 1 B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c7 


c7 


[52] 4.5 


c8 


c8 


11C 


P-Charging-Vector 


[52] 4.6 


c5 


c5 


[52] 4.6 


c6 


c6 


11D 


Privacy 


[33] 4.2 


c3 


c3 


[33] 4.2 


c4 


c4 


11E 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c11 


c11 


11F 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


12 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



c1 : IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization lieader. 



c2: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c3: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c4: IF A.I 62/31 DOR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c5: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c6: IF A.I 62/46 THEN m ELSE IF A.1 62/45 THEN i ELSE n/a -- adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c7: IF A.I 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c8: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c9: IF A.I 62/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

clO: IF A. 162/43 THEN m ELSE IF A.1 62/41 THEN i ELSE n/a -- act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c1 1 : IF A.162/1 1 OR A.162/12 THEN m ELSE i - - reading the contents of the Require header before proxying 
the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c12: IF A.162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 

information. 

c13: IF A.162/70 THEN m ELSE n/a - - SIP location conveyance. 

c14: IF A.162/70A THEN m ELSE IF A.162/70B THEN i ELSE n/a - - addition or modification of location in a SIP 
method, passes on locations in SIP method without modification. 
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Prerequisite A. 163/19 - - REGISTER response 
Prerequisite: A. 164/102 - - Additional for 2xx response 

Table A.279: Supported headers within the REGISTER response 



ItGin 


ncauci 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 




1A 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 




1B 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 




2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


5 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


5A 


P-Assoclated-URI 


[52] 4.1 


c8 


c8 


[52] 4.1 


c9 


clO 


6 


Path 


[35] 4.2 


c3 


c3 


[35] 4.2 


c4 


c4 


8 


Service-Route 


[38] 5 


c5 


c5 


[38] 5 


c6 


c7 


9 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 



cl : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.I 62/29 THEN m ELSE n/a - - Path extension support. 

c4: IF A.I 62/29 THEN i ELSE n/a - - Path extension support. 

c5: IF A.I 62/32 THEN m ELSE n/a - - Service-Route extension support. 

c6: IF A.I 62/32 THEN i ELSE n/a - - Service-Route extension support. 

c7: IF A.162/32 THEN (IF A.3/2 THEN m ELSE i) ELSE n/a - - Service-Route extension and P-CSGF. 

c8: IF A.I 62/36 THEN m ELSE n/a - - the P-Associated-URI extension. 

c9: IF A.I 62/36 THEN i ELSE n/a - - the P-Associated-URI extension. 

clO: IF A.I 62/36 AND A.3/2 THEN m ELSE IF A.I 62/36 AND (A.3/3 OR A.3/9A) THEN i ELSE n/a - - the P- 
Associated-URI extension and P-CSCF or l-CSGF or IBGF (THIG). 



Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A.164/103 OR A.164/104 OR A.164/105 OR A.164/106 - - Additional for 3xx - 6xx response 
Table A.171 A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/1 9 - - REGISTER response 

Prerequisite: A.164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 

Table A.280: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


c2 


c2 


c2: 


IF A.162/19E THEN m ELSE 1 - 


- deleting Contact headers. 
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Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 



Table A.281 : Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


Security-Server 


[48] 2 


X 


c1 


[48] 2 


n/a 


n/a 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


1 


i 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security mechanism agreement for the session initiation protocol. 



Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A.164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Dechne) response 

Table A.282: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


6 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


1 


i 



Table A.283: Void 

Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 

Table A.284: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


9 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A.164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.285: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 
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Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 



Table A.286: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


8 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: 


IF A.1 62/1 7 THEN m ELSE.i 















Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/28 OR A.164/41A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 

Table A.286A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

status 


Profile 
status 


3 


Security-Server 


[48] 2 


Cl 


Cl 


[48] 2 


n/a 


n/a 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security mechanism agreement for the session initiation protocol. 



Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/29 - - Additional for 423 (Interval Too Brief) response 

Table A.287: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Min-Expires 


[26] 20.23 


m 


m 


[28] 20.23 


1 


i 
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Table A.288: Void 
Table A.289: Void 

A.2.2.4.13 SUBSCRIBE method 

Prerequisite A. 163/20 - - SUBSCRIBE request 



Table A.290: Supported headers within the SUBSCRIBE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[261 20.1 


m 


m 


[26] 20.1 


j 


i 


1A 


Accept-Contact 


[56B1 9.2 


c27 


c27 


[56B] 9.2 


c27 


c28 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


j 


j 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 


i 


3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


j 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


7 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


i 


8 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


' 




9 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 






10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


1 


i 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


14 


Event 


[28] 7.2.1 


m 


m 


[28] 7.2.1 


m 


m 


15 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


16A 


Geolocation 


[89] 3.2 


c35 


c35 


[89] 3.2 


c36 


c36 


16B 


History-Info 


[66] 4.1 


c31 


c31 


[66] 4.1 


c31 


c31 


17 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


18 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


18A 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


18B 


P-Access-Networl<- 1 nfo 


[52] 4.4 


c22 


c22 


[52] 4.4 


c23 


c23 


18C 


P-Asserted-ldentity 


[34] 9.1 


c9 


c9 


[34] 9.1 


c10 


c10 


18D 


P-Asserted-Service 


[121] 4.1 


c39 


c39 


[121] 4.1 


c40 


c40 


18E 


P-Called-Party-ID 


[52] 4.2 


c13 


c13 


[52] 4.2 


c14 


c15 


18F 


P-Charging-Function- 
Addresses 


[52] 4.5 


c20 


c20 


[52] 4.5 


c21 


c21 


18G 


P-Charging-Vector 


[52] 4.6 


c18 


c18 


[52] 4.6 


c19 


c19 


18H 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c8 


c8 


181 


P-Preferred-Service 


[121] 4.2 


X 


X 


[121] 4.2 


c38 


c38 


18J 


P-Profile-Key 


[97] 5 


c33 


c33 


[97] 5 


c34 


c34 


18K 


P-User-Database 


[82] 4 


c32 


c32 


[82] 4 


c32 


c32 


18K 


P-Visited-Network-ID 


[52] 4.3 


c16 


n/a 


[52] 4.3 


c17 


n/a 


18M 


Privacy 


[33] 4.2 


c11 


c11 


[33] 4.2 


c12 


c12 


19 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


20 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


20A 


Reason 


[34A] 2 


c25 


c25 


[34A] 2 


c26 


c26 


21 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


21A 


Referred-By 


[59] 3 


c29 


c29 


[59] 3 


c30 


c30 


21B 


Reject-Contact 


[56B] 9.2 


c27 


c27 


[56B] 9.2 


c27 


c28 


21C 


Request-Disposition 


[56B] 9.1 


c27 


c27 


[56B] 9.1 


c27 


c27 


22 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


23 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


23A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c24 


c24 


23 B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c24 


c24 


24 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


25 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


26 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


27 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 
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28 I Via I [26] 20.42 | m Lm | [26] 20.42 | m Lm 

c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A. 162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c4: IF A.162/8A THEN m ELSE 1 - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c6: IF A.162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.1 62/1 4 THEN m ELSE i - - the requirement to be able to insert itself in the subsequent transactions in 

a dialog. 

c8: IF A.I 62/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 
c9: IF A.I 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 
within trusted networks. 

clO: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c1 1 : IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c12: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c13: IF A.I 62/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 
c14: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c15: IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND (A.3/3 OR A.3/9A) THEN i ELSE n/a - - the P- 

Cal led- Party- ID header extension and P-CSCF or l-CSCF or IBCF (THIG). 
c1 6: IF A.I 62/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c1 7: IF A.I 62/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 
request or response. 

c18: IF A. 162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c19: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c20: IF A.I 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c21: IF A.162/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c22: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c23: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c24: IF A. 4/37 A. 1 62/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

c25: IF A. 162/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c26: IF A.162/48 THEN i ELSE n/a - - the Reason header field for the session initiation protocol. 

c27: IF A.I 62/50 THEN m ELSE n/a - - caller preferences for the session initiation protocol. 

c28: IF A.I 62/50 AND A.4/3 THEN m ELSE IF A.I 62/50 AND NOT A.4/3 THEN i ELSE n/a - - caller preferences 

for the session initiation protocol, and S-CSCF. 
c29: IF A.162/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 
c30: IF A.162/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c31 : IF A.I 62/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 
information. 

c32: IF A.I 62/60 THEN m ELSE n/a - - the P-User-Database private header extension. 
c33: IF A.I 62/66A THEN m ELSE n/a - - making the first query to the database in order to populate the P- 
Profile-Key header. 

c34: IF A.162/66B THEN m ELSE n/a - - using the information in the P-Profile-Key header. 
c35: IF A.I 62/70 THEN m ELSE n/a - - SIP location conveyance. 

c36: IF A.I 62/70A THEN m ELSE IF A.I 62/70B THEN i ELSE n/a - - addition or modification of location in a SIP 

method, passes on locations in SIP method without modification. 
c38: IF A.I 62/84A THEN m ELSE n/a - - act as authentication entity within the trust domain for asserted service. 
c39: IF A.I 62/84 THEN m ELSE n/a - - identification of communication services in the session initiation protocol. 
c40: IF A. 162/84 OR A.162/30B THEN m ELSE i - - identification of communication services in the session 

initiation protocol or subsequent entity within trust network that can route outside the trust network. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 

SUBSCRIBE and NOTIFY. 
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Table A.291 : Void 

Prerequisite A. 163/21 - - SUBSCRIBE response 
Prerequisite: A.164/1 - - Additional for 100 (Trying) response 



Table A.291 A: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF (A.162/9 AND A.162/5) OR A.1 62/4 THEN m ELSE n/a 


- - stateful proxy behaviour that inserts date, or 


c2: 


stateless proxies. 

IF A.1 62/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/21 - - SUBSCRIBE response for all remaining status-codes 



Table A.292: Supported headers within the SUBSCRIBE response 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


uali-IU 


[26J 20.8 


m 


m 


[26J 20.8 


m 


m 


2 


Content-Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


i 


3 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


7 


Cseq 


[26] 20.1 6 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


History-Info 


[66] 4.1 


c15 


c15 


[66] 4.1 


c15 


c15 


10 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


10A 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


10B 


P-Access-Network- 1 nfo 


[52] 4.4 


c12 


c12 


[52] 4.4 


c13 


c13 


10C 


P-Asserted-ldentity 


[34] 9.1 


c4 


c4 


[34] 9.1 


c5 


c5 


10D 


P-Cliarging-Function- 

Addresses 


[52] 4.5 


clO 


clO 


[52] 4.5 


cl 1 


cl 1 


10E 


P-Cliarging-Vector 


[52] 4.6 


c8 


c8 


[52] 4.6 


c9 


c9 


10F 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c3 


n/a 


10G 


Privacy 


[33] 4.2 


c6 


c6 


[33] 4.2 


c7 


c7 


10H 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c14 


c14 


101 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



cl : IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 



c2: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c3: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c4: IF A.I 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c5: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c6: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c7: IF A.162/31D OR A.162/31G THEN m ELSE IF A.162/31C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c8: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c9: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Gharging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

clO: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c11: IF A.162/44ATHEN m ELSE IF A.I 62/44 THEN i ELSE n/a -- adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c12: IF A.I 62/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c13: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c14: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 
the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c15: IF A. 162/57 THEN m ELSE n/a - - an extension to the session initiation protocol for request history 
information. 

c16: IF A.162/70 THEN m ELSE n/a - - SIP location conveyance. 

c17: IF A.162/70A THEN m ELSE IF A.I 62/708 THEN i ELSE n/a - - addition or modification of location in a SIP 
method, passes on locations in SIP method without modification. 
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Prerequisite A. 163/21 - - SUBSCRIBE response 
Prerequisite: A. 164/102 - - Additional for 2xx response 



Table A.293: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


i 




1 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 




1A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 




2 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 




3 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c3: IF A.162/15 THEN m ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A.163/21 - - SUBSCRIBE response 

Prerequisite: A.164/103 OR A.164/104 OR A.164/105 OR A.164/106 - - Additional for 3xx - 6xx response 
Table A.293A: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
Status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A.163/21 - - SUBSCRIBE response 

Prerequisite: A.164/103 OR A. 164/35 - - Additional for 3xx or 485 (Ambiguous) response 



Table A.294: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 


Profile 


Ref. 


RFC 


Profile 








Status 


status 




status 


status 


1 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


cl 


c1: 


IF A.I 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A.163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 

Table A.295: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 
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Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A.164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480 (Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 



Table A.296: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 



Table A.297: Void 

Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 



Table A.298: Supported headers within the SUBSCRIBE response 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 

Table A.299: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 

Table A.300: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/28 OR A. 164/41 A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 



Table A.300A: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 






Ret. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security meclianism agreement for the session initiation protocol. 



Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/29 - - Additional for 423 (Interval Too Brief) response 

Table A.301 : Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


IVIin-Expires 


[26] 20.23 


m 


m 


[26] 20.23 


i 


i 



Table A.302: Void 

Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/39 - - Additional for 489 (Bad Event) response 

Table A.303: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


c1 


c1 


c1: 


IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 








NOTE: 


c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 
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Table A.303A: Void 
Table A.304: Void 

A.2.2.4.14 UPDATE method 

Prerequisite A. 163/22 - - UPDATE request 



Table A.305: Supported headers within the UPDATE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[261 20.1 


m 


m 


[26] 20.1 


i 


i 


1A 


Accept-Contact 


[56B1 9.2 


c21 


c21 


[566] 9.2 


c22 


c22 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


j 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 


i 


4 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


5 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


6 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


7 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


8 


Gall-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c8 


c8 


9 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


10 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


c4 


c4 


11 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


c4 


c4 


12 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


c4 


c4 


13 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


14 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


c4 


c4 


15 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


16 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


17 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


17A 


Geolocation 


[89] 3.2 


c26 


c26 


[89] 3.2 


c27 


c27 


18 


IVlax- Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


19 


IVIIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c4 


19A 


Min-SE 


[58] 5 


c23 


c23 


[58] 5 


c23 


c23 


20 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


20A 


P-Access-Networi<-info 


[52] 4.4 


c16 


c16 


[52] 4.4 


c17 


c17 


20B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c14 


c14 


[52] 4.5 


c15 


c15 


20C 


P-Charging-Vector 


[52] 4.6 


c12 


c12 


[52] 4.6 


c13 


c13 


20D 


P-Early-Media 


[109] 8 





c28 


[109] 8 





c29 


20E 


Privacy 


[33] 4.2 


c10 


clO 


[33] 4.2 


c11 


c11 


21 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c9 


c9 


22 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


22A 


Reason 


[34A] 2 


c19 


c19 


[34A] 2 


c20 


c20 


23 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


23A 


Referred-By 


[59] 3 


c24 


c24 


[59] 3 


c25 


c25 


23B 


Reject-Contact 


[56B] 9.2 


c21 


c21 


[568] 9.2 


c22 


c22 


23C 


Request-Disposition 


[56B] 9.1 


c21 


c21 


[568] 9.1 


c22 


c22 


24 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


25 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


25A 


Security-Client 


[48] 2.3.1 


x 


X 


[48] 2.3.1 


c18 


c18 


25B 


Security- Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


25C 


Session-Expires 


[5814 


c23 


c23 


[5814 


c23 


c23 


26 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


27 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


28 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


29 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


30 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE 1 - - insertion of date in requests and responses. 

c3; IF A.162/19A OR A.162/19B THEN m ELSE 1 - - reading, adding or concatenating the Organization header. 

c4: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c6: IF A. 1 62/1 6 THEN m ELSE I - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN o ELSE I - - the requirement to be able to Insert itself In the subsequent transactions In a 

dialog. 

c8; IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c9: IF A.1 62/8A THEN m ELSE I - - authentication between UA and proxy. 

c10: IF A.1 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c11: IF A.162/31D OR A.1 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a -- application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c12: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c13: IF A.1 62/46 THEN m ELSE IF A.162/45 THEN 1 ELSE n/a - - adding, deleting, reading or modifying the P- 
Gharglng-Vector header before proxying the request or response or the P-Charglng-Vector header 
extension. 

c14: IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Functlon-Addresses header extension. 

c15: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c16: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network Information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c17: IF A.162/43 THEN m ELSE IF A.162/41 THEN I ELSE n/a - - act as subsequent entity within trust network 
for access network Information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c18: IF At4/3? A. 162/47 THEN m ELSE n/a - - security mechanism agreement for the session Initiation protocol. 

c1 9: IF A.1 62/48 THEN m ELSE n/a - - the Reason header field for the session initiation protocol. 

c20: IF A.1 62/48 THEN I ELSE n/a - - the Reason header field for the session Initiation protocol. 

c21 : IF A.1 62/50 THEN m ELSE n/a - - caller preferences for the session Initiation protocol. 

c22: IF A.1 62/50 THEN I ELSE n/a - - caller preferences for the session Initiation protocol. 

c23: IF A.1 62/52 THEN m ELSE n/a - - the SIP session timer. 

c24; IF A.162/53 THEN i ELSE n/a - - the SIP Referred-By mechanism. 

c25: IF A.1 62/53 THEN m ELSE n/a - - the SIP Referred-By mechanism. 

c26: IF A.1 62/70 THEN m ELSE n/a - - SIP location conveyance. 

c27: IF A.162/70A THEN m ELSE IF A.162/70B THEN I ELSE n/a - - addition or modification of location In a SIP 

method, passes on locations in SIP method without modification. 
c28: IF A.162/76 THEN m ELSE n/a - - the SIP P-Early-IVIedia private header extension for authorization of early 

media. 

c29: IF A.162/76 THEN (IF A.3/2 THEN m ELSE i) ELSE n/a - - P-CSCF, using the information In the P-Early- 

IVIedia header. 

NOTE: c1 refers to the UA role major capability as this Is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 
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Table A.306: Void 

Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A.164/1 - - Additional for 100 (Trying) response 



Table A.306A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF (A.162/9 AND A.162/5) OR A.1 62/4 THEN m ELSE n/a 


- - stateful proxy behaviour that inserts date, or 


c2: 


stateless proxies. 

IF A.1 62/4 THEN i ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/22 - - UPDATE response for all remaining status-codes 



Table A.307: Supported headers within the UPDATE response 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


A Mm 11 

Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Gall-ID 


[26J 20.8 


m 


m 


[26J 20.8 


m 


m 




^ 1 1 1 L^f ^ 

Oall-lnfo 


[26] 20.9 


m 


m 


[26] 20.9 


c4 


c4 


1 B 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


2 


Content-Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


c3 


3 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


c3 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


c3 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c3 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c1 


Cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9A 


Geolocation 


[89] 3.2 


c14 


c14 


[89] 3.2 


c15 


c15 


10 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


10A 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


10B 


P-Access-Network-lnfo 


[52] 4.4 


c1 1 


c1 1 


[52] 4.4 


c12 


c12 


1 oc 


P-Charging-Function- 
Addresses 


[52] 4.5 


c9 


c9 


[52] 4.5 


clO 


clO 


10D 


P-Ctiarging-Vector 


[52] 4.6 


c7 


n/a 


[52] 4.6 


c8 


n/a 


10E 


Privacy 


[33] 4.2 


c5 


c5 


[33] 4.2 


c6 


c6 


10F 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c13 


c13 


10G 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



cl : IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 



c3: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c5: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c6: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c7: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c8: IF A.162/46THEN m ELSE IF A.I 62/45 THEN i ELSE n/a -- adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c9: IF A.I 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

cl 0: IF A.I 62/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c11: IF A. 162/43 THEN x ELSE IF A.I 62/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c12: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c13: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 
the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c14: IF A.162/70 THEN m ELSE n/a - - SIP location conveyance. 

cl 5: IF A.I 62/70A THEN m ELSE IF A.I 62/70B THEN i ELSE n/a - - addition or modification of location in a SIP 
method, passes on locations in SIP method without modification. 



Prerequisite A. 163/23 - - UPDATE response 
Prerequisite: A. 164/102 - - Additional for 2xx response 
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Table A.308: Supported headers within the UPDATE response 



Itom 

IICI II 




Sending 


Receiving 




nro 




Rof 






OA 




[26] 20.1 


m 


m 


[26] 20.1 


i 




OB 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 




OC 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 




1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


ci 


2 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


3A 


P-Early-Media 


[109] 8 





clO 


[109] 8 





c11 


4 


Session-Expires 


[58] 4 


c4 


c4 


[58] 4 


c4 


c4 


6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 



cl : IF A.4/20 THEN m ELSE i - - SIP specific event notification extension. 

c3: IF A.I 62/1 5 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 

and downstream direction when record routeing. 
c4: IF A.I 62/52 THEN m ELSE n/a - - the SIP session timer. 

clO: IF A. 162/76 THEN m ELSE n/a - - the SIP P-Early-Media private header extension for authorization of early 
media. 

cl 1 : IF A.I 62/76 THEN (IF A.3/2 THEN m ELSE i) ELSE n/a - - P-CSCF, using the information in the P-Early- 
Media header. 



Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A.164/103 OR A.164/104 OR A.164/105 OR A.164/106 - - Additional for 3xx - 6xx response 



Table A.308A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 



Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A.164/103 or A.164/35 - - Additional for 3xx, 485 (Ambiguous) response 



Table A.309: Supported headers within the UPDATE response 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


2 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


cl 


cl 


cl: 


IF A.I 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/14 - - Additional for 401 (Unauthorized) response 



Tabie A.309A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 
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Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/1 7 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/42 OR A. 164/45 OR A. 164/50 OR 
A.164/51 - - Additional for 404 (Not Found), 413 (Request Entity Too Large), 480(Temporarily not available), 486 
(Busy Here), 500 (Internal Server Error), 503 (Service Unavailable), 600 (Busy Everywhere), 603 (Decline) response 



Table A.310: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


5 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 


i 


i 



Table A.311: Void 

Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/20 - - Additional for 407 (Proxy Authentication Required) response 



Table A.312: Supported headers within the UPDATE response 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/25 - - Additional for 415 (Unsupported Media Type) response 



Table A.313: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 







Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/27 - - Additional for 420 (Bad Extension) response 



Tabie A.314: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


7 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/28 OR A. 164/41 A - - Additional for 421 (Extension Required), 494 (Security Agreement Required) 
response 



Table A.314A: Supported headers within the UPDATE response 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security meclianism agreement for the session initiation protocol. 
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Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A.164/28A - - Additional for 422 (Session Interval Too Small) response 



Table A.314B: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Min-SE 


[58] 5 


c1 


c1 


[58] 5 


c1 


c1 


c1: 


IF A.1 62/52 THEN m ELSE n/a 


- - the SIP session timer. 











Table A.315: Void 
Table A.316: Void 

A.3.2.1 Major capabilities 

Table A.317: Major capabilities 



Item 


Does the Implementation support 


Reference 


RFC status 


Profile status 




Capabilities within main protocol 




















Extensions 








22 


integration of resource management and 
SIP? 


[30] [64] 





m 


23 


grouping of media lines 


[531 


c3 


c3 


24 


mapping of media streams to resource 
reservation flows 


[54] 





Cl 


25 


SDP Bandwidth Modifiers for RTCP 

Bandwidth 


[56] 





(NOTE) 


26 


TCP-based media transport in the 
session description protocol 


[83] 





c2 


27 


interactive connectivity establishment? 


[99] 





c4 


28 


session description protocol format for 

binary floor control protocol streams? 


[108] 








c1 : IF A.3/1 THEN mo.1 ELSE n/a - - UE role. 

c2: IF A.3/1 OR A.3/6 OR A.3/7 THEN o ELSE n/a - - UE, MGCF, AS. 

c3: IF A. 31 7/24 THEN m ELSE o - - mapping of media streams to resource reservation flows. 

c4 IF A.3/9B THEN m ELSE IF A.3/1 OR A.3/6 THEN o ELSE n/a - - IBCF, UE, MGCF. 

0.1 : The procedure is mandatory in case if there are access specific procedures which the UE is usina. 


NOTE: For "video" and "audio" media types that utilize RTP/RTCP, f the RTGP bandwidth level for the session is 
different than the default RTCP bandwidth as specified in RFC 3556 [56], then, it shall be specified. For 
other media types, it may be specified. 



A.3.2.2 SDP types 

Table A.318: SDP types 



Item 


Type 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 




Session level description 


1 


v= (protocol version) 


[39] 5.1 


m 


m 


[39] 5.1 


m 


m 


2 


0= (owner/creator and session 
identifier) 


[39] 5.2 


m 


m 


[39] 5.2 


m 


m 


3 


s= (session name) 


[39] 5.3 


m 


m 


[39] 5.3 


m 


m 


4 


i= (session information) 


[39] 5.4 





c2 


[39] 5.4 


m 


c3 


5 


u= (URI of description) 


[39] 5.5 





c4 


[39] 5.5 





n/a 


6 


e= (email address) 


[39] 5.6 





c4 


[39] 5.6 





n/a 


7 


p= (phone number) 


[39] 5.6 





c4 


[39] 5.6 





n/a 


8 


c= (connection information) 


[39] 5.7 


c5 


c5 


[39] 5.7 


m 


m 
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y 


b= (bandwidth information) 


[39] 5.8 







(NOTE 1) 


[39] 5.8 


m 


m 




Time description (one or more per description) 


10 


t= (time tlie session is active) 


[391 5.9 


m 


m 


[39] 5.9 


m 


m 


1 1 


r= (zero or more repeat times) 


[3915.10 





c4 


[39] 5.10 





n/a 




Session level description (continued) 


12 


z= (time zone adjustments) 


[39] 5.11 





n/a 


[39] 5.11 





n/a 


13 


l<= (encryption key) 


[39] 5.12 


X 


X 


[39] 5.12 


n/a 


n/a 


14 


a= (zero or more session 
attribute lines) 


[39] 5.13 








[39] 5.13 


m 


m 




Media description (zero or more per description) 


15 


m= (media name and 
transport address) 


[39] 5.14 








[39] 5.14 


m 


m 


16 


i= (media title) 


[39] 5.4 





c2 


[39] 5.4 





c3 


17 


c= (connection information) 


[39] 5.7 


cl 


cl 


[39] 5.7 


cl 


cl 


18 


b= (bandwidth information) 


[39] 5.8 







(NOTE 1) 


[39] 5.8 






19 


k= (encryption key) 


[39] 5.12 


X 


X 


[39] 5.12 


n/a 


n/a 


20 


a= (zero or more media 
attribute lines) 


[39] 5.13 








[39] 5.13 


m 


m 


Cl: 


IF (A.318/15 AND NOT A.318/8) THEN m ELSE (IF (A.318/15 AND A.318/8) THEN o ELSE n/a) 


-- 'c=' 




contained in session level descriDtion and SDP contains media descriptions. IF A.318/15 THEN m ELSE 


















c2: 


IF A.3A/6 THEN x ELSE o - - MGCF. 












c3: 


IF A.3A/6 THEN n/a ELSE m - - 


MGCF. 












c4: 


IF A.3A/6 THEN x ELSE n/a - - MGCF. 












c5: 


IF A.31 8/1 7 THEN ELSE m - - 


"c=" contained in all media description 








NOTE 1 : 


For "video" and "audio" media types that utilise RTP/RTCP, it shall be specified. For other media types, it 
may be specified. 
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Prerequisite A.3 18/14 OR A.3 18/20 - - a= (zero or more session/media attribute lines) 



Table A.319: zero or more session / media attribute lines (a=) 



Item 


Field 


Sending 


Receiving 






Ref. 


RFC 


Profile 


Ref. 


RFC 


Profile 








Status 


status 




Status 


status 


1 


category (a=cat) 


[39] 6 


c8 


c8 


[39] 6 


c9 


c9 


2 


keywords (a=keywds) 


[39] 6 


c8 


c8 


[39] 6 


c9 


c9 


3 


name and version of tool 


[39] 6 


c8 


c8 


[39] 6 


c9 


c9 




(a=tool) 














4 


packet time (a=ptime) 


[39] 6 


clO 


ClO 


[39] 6 


c11 


c11 


5 


maximum packet time 


[39] 6, 


clO 


clO 


[39] 6, 


Cl1 


Cl1 




(a=maxptime) 


[28A] 8 






[28A] 8 






6 


receive-only mode 


[39] 6 








[39] 6 


m 


m 




(a=recvonly) 














7 


send and receive mode 


[39] 6 








[39] 6 


m 


m 




(a=sendrecv) 














8 


send-only mode (a=sendonly) 


[39] 6 








[39] 6 


m 


m 


8A 


Inactive mode (a=inactive) 


[39] 6 








[39] 6 


m 


m 


9 


whiteboard orientation 


[39] 6 


ClO 


ClO 


[39] 6 


c11 


c11 




(a=orient) 














10 


conference type (a=type) 


[39] 6 


c8 


c8 


[39] 6 


c9 


c9 


11 


character set (a=charset) 


[39] 6 


c8 


c8 


[39] 6 


c9 


c9 


12 


language tag (a=sdplang) 


[39] 6 








[39] 6 


m 


m 


13 


language tag (a=lang) 


[39] 6 








[39] 6 


m 


m 


14 


frame rate (a=framerate) 


[39] 6 


c10 


ClO 


[39] 6 


c11 


c11 


15 


quality (a=quality) 


[39] 6 


clO 


ClO 


[39] 6 


c11 


c11 


16 


format specific parameters 


[39] 6 


ClO 


ClO 


[39] 6 


c11 


c11 




(a=fmtp) 














17 


rtpmap attribute (a=rtpmap) 


[39] 6 


ClO 


ClO 


[39] 6 


Cl1 


Cl1 


18 


current-status attribute 


[30] 5 


c1 


cl 


[30] 5 


c2 


c2 




(a=curr) 














19 


desired-status attribute 


[30] 5 


Cl 


cl 


[30] 5 


c2 


c2 




(a=des) 














20 


confirm-status attribute 


[30] 5 


Cl 


cl 


[30] 5 


c2 


c2 




(a=conf) 














21 


media stream identification 


[53] 3 


c3 


c3 


[53] 3 


c4 


c4 




attribute (a=mid) 














22 


group attribute {a=group) 


[5314 


c5 


c5 


[53] 3 


c6 


c6 


23 


setup attribute (a=setup) 


[8314 


c7 


c7 


[8314 


c7 


c7 


24 


connection attribute 


[83] 5 


c7 


c7 


[83] 5 


c7 


c7 




(a=connection) 














25 


candidate IP addresses 


[99] 


c12 


c12 


[99] 


c13 


c13 




(a=candidate) 














26 


floor control server 


[108] 4 


c14 


c14 


[108] 4 


c14 


c14 




determination (a=floorctrl) 














27 


conference id (a=confid) 


[108] 5 


c14 


c14 


[108] 5 


c14 


c14 


28 


user id (a=userid) 


[108] 5 


c14 


c14 


[108] 5 


c14 


c14 


29 


association between streams 


[108] 6 


c14 


c14 


[108] 6 


c14 


c14 




and floors (a=floorid) 
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c8; 
c9: 
c10 
c11 
c12 
c13 
c14: 



c1: 



c2: 



c3: 
c4: 
c5: 
c6: 



c7: 



IF A.317/22 AND A.318/20 THEN o ELSE n/a - - integration of resource management and SIP, media level 
attribute name "a=". 

IF A.317/22 AND A.318/20 THEN m ELSE n/a - - integration of resource management and SIP, media level 

attribute name "a=". 

IF A.317/23 AND A.318/20 THEN o ELSE n/a - - grouping of media lines, media level attribute name "a=". 
IF A.317/23 AND A.318/20 THEN m ELSE n/a - - grouping of media lines, media level attribute name "a=". 
IF A.317/23 AND A.318/14 THEN o ELSE n/a - - grouping of media lines, session level attribute name "a=". 
IF A.317/23 AND A.318/14 THEN m ELSE n/a - - grouping of media lines, session level attribute name 

"a=". 

IF A. 31 7/26 AND A.318/20 THEN m ELSE n/a - - TCP-based media transport in the dession description 

protocol, media level attribute name "a=". 

IF A.318/14 THEN o ELSE x - - session level attribute name "a=". 

IF A.318/14 THEN m ELSE n/a - - session level attribute name "a=". 

IF A.318/20 THEN o ELSE x - - media level attribute name "a=". 

IF A.318/20 THEN m ELSE n/a - - media level attribute name "a=". 

IF A.317/27 AND A.318/20 THEN o ELSE n/a - - candidate IP addresses, media level attribute name "a=". 
IF A.317/27 AND A.318/20 THEN m ELSE n/a - - candidate IP addresses, media level attribute name "a=". 
IF A.317/28 AND A.318/20 THEN m ELSE n/a - - session description protocol format for binary floor control 
protocol streams, media level attribute name "a=". 



Annex B 



IP-Connectivity Access Network specific concepts when using GPRS to access IM CN 
subsystem 



B.2 



GPRS aspects when connected to the IM CN subsystem 



For the purpose of the present document annex B of [1] appHes, except for subclause B.2. 2.1 which is replaced by the 
appropriate subclause in annex B. In addition subclause B.2A.2 is added. 



Prior to communication with the IM CN subsystem, the UE shall: 

a) perform a GPRS attach procedure; 

If the bearer establishment is controlled by the UE the UE starts reserving its local resources whenever it has 
sufficient information about the media streams, media authorization and used codecs available as specified in 
3GPPTS 24.008 [81. 

NOTE 1 : If the bearer establishment is controlled by the GPRS IP CAN the resource reservation requests are 
initiated by the GGSN after the P-CSCF has authorised the respective IP flows and provided the QoS 
requirements over the Rx interface to the PCRF as described in 3GPP TS 29.214 [1301. 

NOTE lA: During the POP context activation procedure it is negotiated whether the UE or the GPRS IP-CAN is 
responsible for establishing the applicable to all PDP contexts within the activated PDP address/ APN pair 
as described in 3GPP TS 24.008 [81. 

b) establish ensure that a PDP context used for SIP signalling according to the APN and GGSN selection criteria 
described in 3GPP TS 23.060 [4] and 3GPP TS 27.060 [10A1 is available . This PDP context shall remain active 
throughout the period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least 
until the deregistration. As a result, the PDP context provides the UE with information that makes the UE able to 
construct an IPv6 address; 

When the bearer establishment is controlled by the UE, tThe UE shall choose one of the following options when 
performing establishment of this PDP context: 

I. A dedicated PDP context for SIP signalling: 

The UE shall indicate to the GGSN that this is a PDP context intended to carry IM CN subsystem-related 
signalling only by setting the IM CN Subsystem Signalling Flag. The UE may also use this PDP context for 
DNS and DHCP signalling according to the static packet filters as described in 3GPP TS 29.061 [11]. The 
UE can also set the SignalUng Indication attribute within the QoS IE; 

II. A general-purpose PDP context: 



B.2.2.1 



PDP context activation and P-CSCF discovery 
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The UE may decide to use a general-purpose PDP Context to carry IM CN subsystem-related signaling. The 
UE shall indicate to the GGSN that this is a general-purpose PDP context by not setting the IM CN 
Subsystem Signalling Flag. The UE may carry both signalling and media on the general-purpose PDP 
context. The UE can also set the Signalling Indication attribute within the QoS IE. 

NOTE 2: When the bearer establishment is controlled by the GPRS IP -CAN, the GGSN follows the procedures 
described in 3GPP TS 29.061 1 11 1 in order to establish a dedicated PDP context for SIP signalling. 

The UE indicates the IM CN Subsystem Signalling Flag to the GGSN within the Protocol Configuration Options IE of 
the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP CONTEXT REQUEST 
message. Upon successful signalling PDP context establishment the UE receives an indication from GGSN in the form 
of IM CN Subsystem Signalling Flag within the Protocol Configuration Options IE. If the flag is not received, the UE 
shall consider the PDP context as a general-purpose PDP context. 

The encoding of the IM CN Subsystem Signalhng Flag within the Protocol Configuration Options IE is described in 
3GPPTS 24.008 [8]. 

The UE can indicate a request for prioritised handUng over the radio interface by setting the Signalling 
Indication attribute (see 3GPP TS 23.107 [4A]). The general QoS negotiation mechanism and the encoding of 
the Signalling Indication attribute within the QoS IE are described in 3GPP TS 24.008 [8]. 

NOTE^: A general-purpose PDP Context canmay carry both IM CN subsystem signaling and media, in case the 
media does not need to be authorized by Policy and Charging control mechanisms as defined in 
3GPP TS 29.212 [13C] and Service Based Local PoHcy mechanisms defined in 3GPP TS 29.207 [12] and 
the media stream is not mandated by the P-CSCF to be carried in a separate PDP Context. 

c) acquire a P-CSCF address(es). 

The methods for P-CSCF discovery are: 

I. Employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315 [40], the DHCPv6 options for 
SIP servers RFC 3319 [41] and DHCPv6 options for Domain Name Servers (DNS) RFC 3646 [56C] as 
described in subclause 9.2.1. 

n. Transfer P-CSCF address(es) within the PDP context activation procedure. 

The UE shall indicate the request for a P-CSCF address to the GGSN within the Protocol Configuration 
Options IE of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP 
CONTEXT REQUEST message. 

If the GGSN provides the UE with a list of P-CSCF IPv6 addresses in the ACTIVATE PDP CONTEXT 
ACCEPT message or ACTIVATE SECONDARY PDP CONTEXT ACCEPT message, the UE shall assume 
that the list is prioritised with the first address within the Protocol Configuration Options IE as the P-CSCF 
address with the highest priority. 

The UE can freely select method I or II for P-CSCF discovery. In case method I is selected and several P-CSCF 
addresses or FQDNs are provided to the UE, the selection of P-CSCF address or FQDN shall be performed as indicated 
in RFC 3319 [41]. If sufficient information for P-CSCF address selection is not available, selection of the P-CSCF 
address by the UE is implementation specific. 

If the UE is designed to use 1 above, but receives P-CSCF address(es) according to II, then the UE shall either ignore 
the received address(es), or use the address(es) in accordance with II, and not proceed with the DHCP request according 
to I. 

The UE may request a DNS Server IPv6 address(es) via RFC 3315 [40] and RFC 3646 [56C] or by the Protocol 
Configuration Options IE when activating a PDP context according to 3GPP TS 27.060 [lOA]. 

The encoding of the request and response for IPv6 address(es) for DNS server(s) and list of P-CSCF address(es) within 
the Protocol Configuration Options IE is described in 3GPP TS 24.008 [8]. 

B.2A.2 Handling of SDP at the terminating UE when originating UE has resources available 

and IP-CAN performs network-initiated resource reservation for terminating UE 

If the UE receives an SDP offer where the SDP offer includes all media streams for which the originating side indicated 
its local preconditions as met, if the precondition mechanism is supported by the terminating UE and the IP-CAN 
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performs network-initiated resource reservation for the terminating UE and the available resources are not sufficient for 
the received offer the terminating UE shall indicate its local preconditions and provide the SDP answer to the 
originating side without waiting for resource reservation. 

NOTE 1: If the resource reservation is controlled by the GPRS IP-CAN, the resource reservation request is initiated 
by the GGSN after the P-CSCF has authorised the respective IP flows and provided the QoS requirements 
over the Rx interface to the PCRF as described in 3GPP TS 29.214 [13D1. 

NOTE 2: During the PDF context activation procedure the UE and network negotiate whether the UE or the GPRS 
IP-CAN is responsible to the resource reservation applicable to ail PDP contexts within the activated PDF 
address/APN pair as described in 3GPP TS 24.008 [81. 

Annex C UlCC and USIM Aspects for access to the IM CN subsystem 

For the purpose of the present document annex C of [1] applies, except for the addition of clause C.4. 

C.4 Provisioning of MS parameters for UEs without ISIM or USIM 

In case the UE contains neither a USIM application nor a ISIM appUcation. the following IMS parameters are assumed 
to be available to the UE: 

- a private user identity; 

- a public user identity; and 

- a home network domain name to address the SIP REGISTER request to. 
These parameters may not necessarily reside in a UICC. 

Annex D IP-Connectivity Access Network specific concepts when using I-W1_AN to access IM 

CN subsystem 

For the purpose of the present document annex D of [1] apphes. 

Annex E IP-Connectivity Access Network specific concepts when using xDSL to access IM CN 

subsystem 

For the purpose of the present document annex E of [1] applies. 
Annex F 

Annex F applies with the exception that all occurrences of "IMS Access Gateway" and IMS Access Gateway over the 
Iq interface" are replaced with "transport fimctions". 

For the purpose of this document annex F of [1] applies with the addition of clause F.4A. 

F.2.1.2.2 Initial registration 

Subclause F.4.1 applies with the following modification to item d). 

Modify item d) as follows: 

d) a Contact header according to the following rules: if the REGISTER request is sent without integrity protection, 
the Contact header shall be set to include SIP URI(s) containing the private IP address of the UE in the hostport 
parameter or FQDN. If the UE supports GRUU, it shall include a H-sip. instance parameter containing the instance 
ID. If the REGISTER request is integrity protected, the UE shall include the public IP address or FQDN and the 
protected server port value in the hostport parameter. The UE shall only use a FQDN in a protected REGISTER 
request, if it is ensured that the FQDN resolves to the public IP address of the NAT. If the UE supports GRUU, it 
shall include a H-sip. instance parameter containing the instance ID. The UE shall include all supported ICSI 
values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref feature tag as defined in subclause 7.9.2 
and RFC 3840 [621 for the IMS communication services it intends to use, and lARI values (coded as specified in 
subclause 7.2A.9.2), for the IMS apphcations it intends to use in a g.3gpp.iari-ref feature tag as defined in 
subclause 7.9.3 and RFC 3840 |62| ; 
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F.2. 1 .2.4 User-initiated re-registration 

Subclause F.4.1 applies with the following modification to item d). 
Modify item d) as follows: 

d) a Contact header set to include SIP URI(s) that contain(s) in the hostport parameter the pubUc IP address of the 
UE or FQDN and protected server port value bound to the security association, and containing the instance ID of 
the UE in the H-sip.instance parameter, if the UE supports GRUU. The UE shall only use a FQDN, if it is ensured 
that the FQDN resolves to the public IP address of the NAT . The UE shall include all supported ICSI values 
(coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref feature tag as defined in subclause 7.9.2 and 
RFC 3840 [621 for the IMS communication services it intends to use, and lARI values (coded as specified in 
subclause 7.2A.9.2), for the IMS apphcations it intends to use in a g.3gpp.iari-ref feature tag as defined in 
subclause 7.9.3 and RFC 3840 [621 ; 

F.4A NAT traversal for media 

To keep NAT bindings and firewall pinholes open with uni-directional RTP traffic and enable the C-BGF to perform 
address latching, the UE shall send keep alive messages for each media stream. These messages shall be sent regardless 
of whether the media stream is currently inactive, send only, recvonly or sendrecv. It is recommended that the keepalive 
message be an empty (no payload) RTP packet with a payload type of 20 as long as the other end has not negotiated the 
use of this value. If this value has already been negotiated, then some other imused static payload type from Table 5 of 
RFC 3551 [891 shall be used. 

F.4.1 Introduction 

Subclause F.4.1 applies with the following modification to the first paragraph. 
Modify the first paragraph as follows: 

The procedures defined in subclause F.2 and F.3 remain unchanged except as noted below when This subclause 
describes the SIP procedures for supporting hosted NAT scenarios in case UDP encapsulated IPsec is not employed. In 
these scenarios the procedures for NAT traversal must take into account that all SIP requests and responses are not 
protected by an IPsec security association. 

F.4.2 Registration 

The procedures described in subclause F.4.2 apply with the following modifications. 

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall behave as of subclause F.4.2 with the 
addition of sub-item 6a). 

The P-CSCF shall: 

6a) If a P-CSCF registration timer is running, the P-CSCF may decide not to forward the REGISTER request if received 
half of the time before expiry of the S-CCF registration timer, unless the request is intended to update its capabilities 
according to RFC 3840 [621 or to modify the ICSI values or lARI values that the UE intends to use in the g.ims.app-ref 
feature tag. . In such cases it shall build a 200 OK response, based on the contents of the 200 OK response to the 
previous REGISTER request and forward this response to the UE . 

When the P-CSCF receives a 200 (OK) response to a REGISTER request, the P-CSCF shaU behave as of clause 5.2.2 
with the addition of item 10: 

10) Modify the value of the Expires header field and/or Expires parameter in the Contact header according to the 
transport protocol. In order to minimize the number of REGISTER requests to the S-CCF, it may also start a 
P-CSCF registration timer with a value of 600 seconds if the value received from the S-CCF was for greater than 
1200 seconds, or to half of the time otherwise. 

NOTE 1 : The selected value should be smaller than twice the value of the NAT timeout for the transport protocol. 
For UDP, many NATs have a timeout as low as 30 seconds. Issues such as battery consumption might 
motivate longer NAT timeout values. . 

NOTE 2: If outbound keep alive messages (See annex K) are received before the REGISTER message, this 
procedure is not required. 



ETSI 



Release 7 



210 



ETSI TS 124 503 V8.6.0 (2009-09) 



Annex G 

Annex G applies with the exception that all occurrences of "IMS Access Gateway" and IMS Access Gateway over the 
Iq interface" are replaced with "transport functions". 

Annex J CPC parameter definition 

J.1 Introduction 

This annex defines the use of the "CPC" URI parameter for use within SIP URI and Tel URI in the P- Asserted ID in the 
initial INVITE. 

Editor's note: This annex is based on draft-mahy-iptel-cpc-04.txt and can be removed when the internet draft 

becomes an RFC and the usage of the CPC is allowed for SIP URI. If this solution does not become an 
RFC, this parameter wiU be documented in the present document. 

The Calling Party's Category is represented as a tel URI or SIP URI parameter in a SIP request . The ABNF syntax is as 

follows: 

cpc = cpc-tag "=" cpc-value 

cpc-tag = "cpc" 

cpc-value 

= "ordinary" / "test" / "operator" / 
"payphone" / "priority" / "data" / 

"cellular" / "cellular-roaming" / ' ieps ' / "unknown" / 

genvalue 

genvalue = 1* (alphanum / "-" / "." ) 

The Accept- Language header shall be used to express the language of the operator. 

The semantics of these Calling Party's Category values are described below: 

ordinary: The caller has been identified, and has no special features. 

test: This is a test call that has been originated as part of a maintenance procedure. 

operator: The call was generated by an operator position. 

payphone: The calling station is a payphone. 

priority: Calling subscriber with prioritv. 

data: Data call (voice band data). 

cellular: The calling station is a radio-telephone operating in its home network. 

cellular-roaming: The calling station is a radio-telephone roaming in another network 

ieps: This call is an ieps call 

unknown: The CPC could not be ascertained. 

NOTE 1: The choice of CPC values and their use are up to the Service Provider. CPC values can be exchanged 
across networks if specified in a bilateral agreement between the service providers. 

NOTE 2: Additional national/regional CPC values may exist (e.g. prison, police, hotel, hospital, . . .) 
J. 2 Trust domain 

Entities in the IM CN subsystem shall restrict CPC tel URI or SIP URI parameter to specific domains that are trusted 
and support the CPC parameter. Therefore for the purpose of the CPC parameter within this specification, a trust 
domain also applies. This trust domain is identical to that of the P-Asserted-Identity. If the communication is to be 
passed to an untrusted network or a network not supporting the CPC the CPC parameter shall be removed. 

SIP functional entities within the trust domain will need to take action on the removal of the CPC parameter when the 
SIP signalling crosses the boundary of the trust domain. 
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J.9A Procedures at the S-CCF at the terminating network 

The S-CCF at the terminating network shall delete any CPC parameter in each initial request for a dialog or a request 
for a standalone transaction in the tel URI or SIP URI of the P-Asserted-Identity before forwarding the request to the 
terminating user. 

Add annex L 

Annex L (normative): 

SIP Digest 

Editor's Note: It is FFS whether the SIP digest and TLS procedures will be documented as shown here in annex- 
L, or will be organized in some other manner within this specification (for example, integrated 
with the procedures in the main body of this specification). Therefore, this annex can be regarded 
as a temporary place-holder for this material. 

LI Scope 

This annex describes the procedures to support SIP digest as an additional authentication mechanism, and to support 
TLS as an additional signalling security mechanism between the UE and P-CSCF. SIP digest is optional to implement. 
When SIP digest is supported, TLS can be used as an optional security mechanism. A UE, P-CSCF, or S-CCF that 
implements SIP digest shall support the requirements specified in subclause L.2. A UE or P-CSCF that implements TLS 
shall support the requirements specified in subclause L.3. 

L2 SIP digest 

L2.1 Procedures at the UE 

L2.1.1 General 

A UE that implements SIP digest shall support the procedures specified in subclause 5.1, except as noted in the sub- 
clauses of this section. When performing the procedures of this annex and the procedures in subclause 5.1, the UE shall 
not apply procedures related to IPsec. These procedures are distinguished by the use of the term "security association". 

When using SIP digest without TLS, the UE shall populate the Contact header with the port value of an unprotected 
port where the UE expects to receive requests from the P-CSCF. 

If SIP digest is used without TLS, the UE shall not include RFC 3329 [481 headers in any SIP messages. 

L2.L2 Registration 

L.2. 1.2.1 Initial REGISTER 

When performing SIP digest, the procedures of subclause 5.1.1.2 apply with the following differences. 

The UE shall use the locaUy available public user identity, the private user identity, and the domain name to be used in 
the Request-URI in the registration. The method whereby the public user identity and private user identity are made 
available to the UE is outside the scope of this document (e.g. a public user identity could be input by the end user). 

For SIP digest, if the UE is configured not to use TLS, the UE shall not establish a TLS session toward the P-CSCF. 

L.2.1 .2.2 Subscription to the registration-state event package 

When performing SIP digest, the procedures of subclause 5.1.1.3 apply with the following differences. 

When using SIP digest without TLS, the UE shall populate the Contact header of the SUBSCRIBE request with the port 
value of an unprotected port where the UE expects to receive subsequent mid-dialog requests. 

L2.L2.3 User-initiated reregistration and registration of an additional public user identity 

When performing SIP digest, the procedures of subclause 5.1.1.4 apply with the following differences. 
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On sending a REGISTER request that does not contain a challenge response, the UE shall populate the nonce directive 
with the empty value. 

When using SIP digest without TLS. the UE shall populate the Contact header of the REGISTER request with the port 
value of an unprotected port where the UE expects to receive subsequent requests. 

When using SIP digest without TLS, the UE shall populate the Via header of the REGISTER request with the port value 
of an unprotected port where the UE expects to receive responses to the request. 

L.2.1 .2.4 General Authentication 

When performing SIP digest, the procedures in subclause 5.1.1.5.1 apply with the following differences. 

On receiving a 401 (Unauthorized) response to the REGISTER request, and where the algorithm parameter is MD5, the 
UE shall extract the digest-challenge parameters as indicated in RFC 2617 1211 from the WWW -Authenticate header. 
The UE shall calculate digest-response parameters as indicated in RFC 2617 [211. The UE shall send another 
REGISTER request containing an Authorization header containing a challenge response. If SIP digest is used without 
TLS, the UE shall not include RFC 3329 [481 headers with this REGISTER. 

On receiving the 200 (OK) response for the REGISTER request, if the algorithm parameter in the Authentication-Info 
header is MD5, the UE shall authenticate the S-CCF using the "response-auth" directive in the Authentication-Info 
header as described in RFC 2617 [211. 

On receiving a 403 (Forbidden) response, the UE shall consider the registration to have failed. If performing SIP digest 
with TLS, the UE should send an initial REGISTER according to the procedure specified in subclause 5.1.1.2 if the UE 
considers the TLS session to be no longer active at the P-CSCF. 

L.2.1 .2.5 User-initiated deregistration 

When performing SIP digest, the procedures in subclause 5.1.1.6 apply with the following differences. 

On sending a REGISTER request, the UE shall populate the nonce directive with the empty value. 

When using SIP digest without TLS, the UE shall populate the Contact header of the REGISTER request with the port 
value of an unprotected port where the UE expects to receive subsequent mid-dialog requests. 

When using SIP digest without TLS, the UE shall populate the Via header of the REGISTER request with the port value 
of an unprotected port where the UE expects to receive responses to the request. 

L2.1.3 Generic procedures applicable to all methods excluding the REGISTER method 

When performing SIP digest, the procedures in subclause 5.1.2A and subclause 5.1.3 apply with the following 
differences. 

When using SIP digest without TLS, if the UE does not support GRUU the UE shall populate the Contact header of the 
request with the port value of an unprotected port where the UE expects to receive subsequent mid-dialog requests. 

When using SIP digest without TLS, the UE shall populate the Via header of the request with the port value of an 
unprotected port where the UE expects to receive responses to the request. 

Upon receiving a 407 (Proxy Authentication Required) response to an initial request, the originating UE shall: 

extract the digest-challenge parameters as indicated in RFC 2617 [211 from the Proxy-Authenticate header field; 

- calculate the response as described in RFC 2617 [211; and 

send a new request containing a Proxy- Authorization header in which the header fields are populated as defined 
in RFC 2617 [211 using the calculated response. 
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L2.2 Procedures at the P-CSCF 

L.2.2.1 General 

A P-CSCF that implements SIP digest with or without TLS shall support the procedures specified in subclause 5.2, 
except as noted in the subclauses of this subclause. When performing the procedures of this annex and the procedures in 
subclause 5.2, the P-CSCF shall not apply procedures related to IPsec. These procedures are distinguished by the use of 
the term "security association". 

For SIP digest authentication, the P-CSCF can be configured to have TLS required or disabled: 

- if TLS is required, the P-CSCF shall require the establishment of a TLS session from all SIP digest UEs, in order 
to access IMS subsequent to registration; or 

if TLS is disabled, the P-CSCF shall not allow the establishment of a TLS session from any UE. 

NOTE: The mechanism to configure the P-CSCF to haye TLS required or disabled is outside the scope of this 
specification. 

If SIP digest is used without TLS, the P-CSCF shall discard any SIP messages receiyed outside of the registration and 
authentication procedures that do not map to an existing IP association as defined in subclause L.2.2.2. 

L2.2.2 Registration 

When performing SIP digest, the procedures in subclause 5.2.2 apply with the following differences. 

When not applying TLS, the P-CSCF shall not include RFC 3329 [481 headers in registration messages towards the UE. 

When the P-CSCF receiyes a REGISTER request from the UE, the P-CSCF shall: 

1) replacing step 4, if SIP digest is used without TLS, the P-CSCF shall not include the integrity-protected 
parameter. 

When the P-CSCF receives a 200 (OK) response to a REGISTER request and the value of the Expires header field 
and/or expires parameter in the Contact header is different than zero, then the P-CSCF shall: 

- in addition to the procedures in step 3, create an IP association by storing and associating the UE's packet source 
IP address along with the "sent-by" parameter of the Via header, cf. RFC 3261 [261, of the REGISTER message 
with the private user identity and all the successfully registered public user identities related to that private user 
identity. If draft-ietf-sip-outbound [921 is used then the P-CSCF shall also include the UE's packet source port of 
the REGISTER message as part of the IP association; and 

- replacing step 9: if SIP digest is used without TLS, send the 200 (OK) response to the UE unprotected as defined 
in clause 4 of RFC 3581 [56A1; 

L.2.2.3 Requests initiated by the UE 

When performing SIP digest, the procedures in subclause 5.2.6.3 apply with the following differences. 

When the P-CSCF receives from the UE an initial request for a dialog or a request for a standalone transaction, and the 
request contains a P-Preferred-Identity header that does not match one of the registered public user identities mapped to 
the IP association, or does not contain a P-Preferred-Identity header, the P-CSCF shall identify the initiator of the 
request by a default pubhc user identity. If there is more than one default public user identity available, the P-CSCF 
shall randomly select one of them. 

When the P-CSCF receives any Ixx or 2xx response to an initial request for a dialog, the P-CSCF shall: 

- if SIP digest is used without TLS, in the response rewrite its own Record Route entry to its own SIP URl that 
contains an unprotected server port number where the P-CSCF expects subsequent requests from the UE. 

L.2.2.4 Requests terminated by the UE 

When performing SIP digest, the procedures in subclause 5.2.6.4 apply with the following differences. 
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When the P-CSCF receives, destined for the UE, an initial request for a dialog or a target refresh request for a dialog, 
and SIP digest is used without TLS. prior to forwarding the request, the P-CSCF shall: 

- when adding its own SIP URI to the top of the hst of Record-Route headers and saving the list, build the 

P-CSCF URI in a format that contains an unprotected server port number where the P-CSCF expects subsequent 
requests from the UE; and 

when adding its own address to the top of the received list of Via headers and saving the list, build the P-CSCF 
Via header entry in a format that contains an unprotected server port number where the P-CSCF expects 

responses to the current request from the UE. 

When the P-CSCF receives, destined for the UE. a request for a standalone transaction, or a request for an unknown 
method (that does not relate to an existing dialog), or a response to this request and SIP digest is used without TLS, 
prior to forwarding the request, the P-CSCF shall: 

when adding its own address to the top of the received list of Via headers and saving the list, build the P-CSCF 
Via header entry in a format that contains an unprotected server port number where the P-CSCF expects 
responses to the current request from the UE. 

L.2.2.5 General emergency services 

When performing SIP digest procedures without TLS, the procedures in subclause 5.2.10.1 apply with the following 
differences. 

NOTE: If only emergency setup from registered users is allowed, a request from an unregistered user is ignored 
since it is received outside of the IP association. 

L2.3 Procedures at the S-CCF 

L2.3.1 Initial registration and user-initiated reregistration 

L2.3.1.1 Unprotected REGISTER 

When performing SIP digest, the procedures in subclause 5.4. 1.2.1 apply with the following differences. 

If the S-CCF receives a REGISTER request with a non-empty response parameter in the Authorization header, the 
S-CCF shall follow the protected REGISTER procedures as described in subclause 5.4.1.2.2. 

NOTE: When SIP digest is used without TLS, the "integrity-protected" parameter can not be used to differentiate 
between an initial REGISTER or a protected REGISTER. 

Upon receipt of a REGISTER request without an "integrity-protected" parameter or an "integrity-protected" parameter 
with the value "tls-yes". which is not for an already registered pubUc user identity linked to the same private user 
identity, the S-CCF shall: 

1) in Step 5. challenge the user by generating a 401 (Unauthorized) response for the received REGISTER request, 
including a WWW -Authenticate header as defined in RFC 2617 [211, which transports: 

a protection domain in the realm field; 

- a domain field; 

- a nonce field; 

- an algorithm field; if the algorithm value is not provided in the authentication vector, it shall have the value 
"MD5"; and 

- a qop field; if the qop value is not provided in the authentication vector, it shall contain the value "auth". 
NOTE: This specification does not make any assumption on which network entity generates the nonce. 

L.2.3.1.2 Protected REGISTER 

When performing SIP digest, the procedures in subclause 5.4.1.2.2 apply with the following differences. 
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Upon receipt of a REGISTER request with the "integrity-protected" parameter in the Authorization header set to "tls- 
yes", or for SIP digest authentication without TLS, with a non-empty response parameter in the Authorization header, 
the S-CCF shall identify the user by the pubUc user identity as received in the To header and the private user identity as 
received in the Authorization header of the REGISTER request, and: 

In the case that a timer reg-await-auth is running for this user the S-CCF shall: 

1) in Step 3, in the case the algorithm is MD5, check the following additional fields: 
- a realm field matching the realm field in the authentication challenge; 

nonce field matching the nonce field in the authentication challenge; 
a cnonce field; and 
a nonce-count field. 

The S-CCF shall only proceed with the following steps in this paragraph if the authentication challenge response 
was included: 

2) in Step 4, check whether the received authentication challenge response and the expected authentication 
challenge response match. The expected response is calculated by the S-CCF as described in RFC 2617 [211 
using the H(A1) value provided by the HSS; 

When creating a 200 (OK) for the REGISTER request, the S-CCF shall store the nonce-count value in the received 
REGISTER request and include an Authentication-Info header containing the fields described in RFC 2617 [21] as 
foUows: 

- a nextnonce field if the S-CCF requires a new nonce for subsequent authentication responses from the UE; 
a message-qop field matching the qop in Authorization header sent by the UE; 

a response-auth field with a response-digest calculated as described in RFC 2617 [211; 

- a cnonce field matching the cnonce in the Authorization header sent by the UE; and 

- a nonce-count field matching the nonce-count in the Authorization header sent by the UE. 

L.2.3.1.3 Abnormal cases 

When performing SIP digest, the procedures in subclause 5.4.1.2.3 apply with the following differences. 

In the case that the REGISTER request, that contains the authentication challenge response from the UE does not match 
with the expected REGISTER request (e.g. wrong Call-Id or authentication challenge response) and the request has the 
"integrity-protected" parameter in the Authorization header set to "tls-yes" or contains no "integrity-protected" 
parameter, the S-CCF shall do one of the following: 

- send a 403 (Forbidden) response to the UE. The S CSCF shall consider this authentication attempt as failed. The 
S-CCF shall not update the registration state of the subscriber; or 

- rechallenge the user by issuing a 401 (Unauthorized) response including a challenge as per procedures described 
in subclause 5.4.1.2.1 starting at step 6). 

NOTE: If the UE was registered before, it stays registered until the registration expiration time expires. 

In the case that the REGISTER request from the UE contains an invalid nonce with a valid challenge response for that 
nonce (indicating that the client knows the correct usemame/password), or when the nonce-count value sent by the UE 
is not the expected value, the S-CCF shall: 

- send a 401 (Unauthorized) response to initiate a further authentication attempt with a fresh nonce and the stale 
parameter set to true. 

L2.3.2 User-initiated deregistration 

When performing SIP digest, the procedures in subclause 5.4.1.4 apply with the following differences. 



ETSI 



Release 7 216 ETSI TS 1 24 503 V8.6.0 (2009-09) 

When the S-CCF receives a REGISTER request with the Expires header field containing the value zero, the S-CCF 
shall: 

- check whether the "integrity-protected" parameter in the Authorization header field set to "yes" or "tls-yes", 
indicating that the REGISTER request was received integrity protected. If the "integrity-protected" parameter is 
not present the S-CCF shall ensure authentication is performed as described in subclause 5.4.1.2.1 (and 
consequently subclause 5 .4. 1.2.2) if local policy requires. The S-CCF shall only proceed with the following steps 
if the "integrity-protected" parameter is set to "yes", "tls-yes", or the required authentication is successfully 
performed if required by local policy. 

L.2.3.3 General treatment for all dialogs and standalone transactions excluding requests 

terminated by the S-CCF 

When performing SIP digest, the procedures in subclause 5.4.3 apply with the following differences. 

When the S-CCF receives from the served user an initial request for a dialog or a request for a standalone transaction, 
the S-CCF may perform the steps in subclause L.2.3.4 to challenge the request based on local policy. 

L.2.3.4 General authentication procedures for all SIP reguest methods initiated by the UE 

excluding REGISTER 

L2.3.4.1 General 

When the S-CCF receives from the UE a request (excluding REGISTER), the S-CCF may perform the following steps 
if authentication of SIP request methods initiated by the UE excluding REGISTER is desired: 

1) The S-CCF shall identify the user by the public user identity as received in the P-Asserted-Identity header. 

2) If the public user identity does not match one of the registered public user identities, and the public user identity 
does not match one of the registered wildcarded pubUc user identities, the S-CCF may reject the request with a 
400 (Bad Request) response or silently discard the request. 

3) If the request does not contain a Proxy-Authorization header or the Proxy-Authorization header does not contain 
a digest response, the S-CCF shall: 

a) challenge the user by generating a 407 (Proxy Authentication Required) response for the received request, 
including a Proxy-Autlicnticatc licadcr as defined in RFC 2617 |21 1. wliich includes: 

a protection domain in the realm field; 

- a domain field; 

- a nonce field; 

- an algorithm field; if the algorithm value is not provided in the authentication vector, it shall have the 
value "MD5"; and 

- a qop field; if the qop value is not provided in the authentication vector, it shall have the value "auth". 
Editor's Note: It is FFS which entity generates the nonce. 

b) send the so generated 407 (Proxy Authentication Required) response towards the UE; and 

c) retain the nonce and initialize the corresponding nonce count to a value of 1 . 

4) If the request contains a Proxy- Authorization header, the S-CCF shall: 
a) check whether the Proxy-Authorization header contains: 

the private user identity of the user in the username field; 

an algorithm field which matches the algorithm field in the authentication challenge (i.e. MD5); 

- a response field with the authentication challenge response; 
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- a realm field matching the realm field in the authentication challenge; 

nonce field matching the expected nonce fi"om either a recent authentication challenge or a more recent 
nextnonce sent in an Authentication-Info header; 

- a cnonce field; and 

a nonce-count field with a value that equals the nonce-count expected by the S-CCF. The S-CCF may 
choose to accept a nonce-count which is greater than the expected nonce-count only if the S-CCF uses 
this nonce-count once authentication is successful (and increments it for any subsequent authentication 
responses). 

If any of the aboye checks do not succeed, the S-CCF shall proceed as described in subclause L.2.3.4.2, and 
skip the remainder of this procedure. 

b) check whether the received authentication challenge response and the expected authentication challenge 
response match. The S-CCF shall compute the expected digest response as described in RFC 2617 1211 using 
the H(A1) value contained within the authentication vector, and other digest parameters (i.e. nonce, cnonce, 
nonce-count, qop). 

In the case where the digest response does not match the expected digest response calculated by the S-CCF, the S-CCF 
shall consider the authentication attempt as failed and do one of the following: 

1) rechallenge the user by issuing a 407 (Proxy Authentication Required) response including a challenge as per 
procedures described in this subclause; or 

2) reject the request by issuing a 403 (Forbidden) response; or 

3) reject the request without sending a response. 

In the case where the digest response matches the expected digest response calculated by the S-CCF, the S-CCF shall 
consider the identity of the user verified and the request authenticated. 

L2.3.4.2 Abnormal cases 

In the case that SIP digest is used and the request from the UE contains an invalid nonce with a valid challenge response 
for that nonce (indicating that the client knows the correct username/password), or when the nonce-count value sent by 
the UE is not the expected value, or when the Authorization header does not include the correct parameters, the S-CCF 
shall: 

send a 407 (Proxy Authentication Required) response to initiate a further authentication attempt with a fresh 
nonce and the stale parameter set to true. 
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Annex ZA (informative): 

ZA.1 Void 
ZA.2 Void 
ZA.3 Void 
ZA.4 Void 
ZA.5 Void 
ZA.6 Void 
ZA.7 Void 
ZA.8 Void 
ZA.9 Void 
ZA.9A Void 
ZA.10 Void 
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ZA.1 1 Extensions needed in table A.1 62 of ES 283 003 



Table A.1 62: Major capabilities 



Item 


Does the Implementation support 


Reference 


RFC status 


Profile status 




Capabilities within main protocol 






































XX 


an extension to the session initiation 
protocol for request cpc Information? 


[XX] 


(note) 


cxx 


cxx A.3/2 OR A.3/3 OR A.3/4 OR A.3.5 OR A.3/6 OR A.3/7 OR A.3/8 THEN o ELSE n/a - - 
cpc URI parameter 


NOTE: It has to be clarified within the draft that the cpc value belongs to the trust domain and 
shall not be populated by UE"s 
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Annex ZB (informative): 
Procedures 

For providing services and PSTN/ISDN interoperability it MUST be possible to include a Q.850 Cause value in Reason 
header field of a response. 

The Reason Header is defined within RFC 3326 [34AJ. 
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Annex ZC (normative): 
UUI Header Field 

For the piupose of the present document annex ZC is added. 

ZC.1 Introduction 

This annex defines the use of the UUI Header Field for use within SIP URI and Tel URI. 

Editor's note: This annex is based on draft-johnston-sipping-cc-uui-02.txt and can be removed when the internet 
draft becomes an RFC and the usage of the UUI is allowed for SIP Methods and Responses. If this 
solution does not become an RFC, this parameter wiU be documented in the present document. 

The UUI is represented header field parameter in a SIP request or response as described as follows. 

The ABNF syntax is as follows: 

The User-to-User header field can be present in INVITE requests and 

responses only and in BYE requests and responses. 



The following syntax specification uses the augmented Backus-Naur 
Form (BNF) as described in RFC 2234 and extends RFC 3261. 



UUI = "User-to-User" HCOLON uuidata * {SEMI uui-param) 

uuidata = token 

uui-param = enc-param | generic -param 

enc-param = "encoding=" ("hex" | token) 



The only defined parameter for the 
encoding parameter. "encoding=hex" 
information is encoded as hex digi 
also be standardized. 



User-to-User header field is the 
is used to indicate that the UUI 
s. Other encoding methods may 



ZC.2 Procedures at the terminating network 

The UUI Header Field is a transparent field including information sent end to end. Based on operator pohcy the UUI 
header field may be deleted by the S-CCF or at the network boundary. 
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ZC.3 Extensions needed in table A.4 of ES 283 003 



Table A.4: Major capabilities 



Item 


Does the implementation support 


Reference 


RFC status 


Profile status 




Capabilities within main protocol 






































XX 


an extension to the session initiation 
protocol foe UUI information? 


[XX] 


(note) 


cxx 


cxx A.3/2 OR A.3/3 OR A.3/4 OR A.3.5 OR A.3/6 OR A.3/7 OR A.3/8 OR A.3/9 OR A.3/1 
OR A.3/1 1 THEN o ELSE n/a - - UUI Header Field 


NOTE: It has to be clarified within the draft that the cpc value belongs to the trust domain and 
shall not be populated by UE"s 



ZC.4 Extensions needed in table A. 162 of ES 283 003 



Table A.162: Major capabilities 



Item 


Does the implementation support 


Reference 


RFC status 


Profile status 




Capabilities within main protocol 






































XX 


an extension to the session initiation 
protocol for request UUI information? 


[XX] 


(note) 


cxx 


cxx A.3/2 OR A.3/3 OR A.3/4 OR A.3.5 OR A.3/6 OR A.3/7 OR A.3/8 OR A.3/9 OR A.3/1 
OR A.3/1 1 THEN o ELSE n/a - - UUI Header Field 


NOTE: It has to be clarified within the draft that the cpc value belongs to the trust domain and 
shall not be populated by UE"s 
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Annex ZD (normative): 
XML schema for PSTN 

<?xml version="1.0" encoding="UTF-8"?> 
<xs: schema xmlns:xs="http://www. w3.org/2001/XMLSchema" 
xmlns="http://uri.etsi.org/ngn/params/xml/simservs/pstn" 
xmlns:nsl="http://uri.etsi.org/ngn/params/xml/simservs/ pstn" 
targetNamespace="http://uri.etsi.org/ngn/params/xml/simservs/ pstn" 
elementFormDefault="qualified"> 
<xs:annotation> 

<xs:documentation>XML Schema definition for mapping of some PSTN into SIP MIME 
Bodies</xs:documentation> 
</xs:annotation> 
<!— Definition of simple types~> 
<xs:simpleType name="OneBitType"> 
<xs:restriction base="xs:string"> 

<xs:pattem value="[0-l]"/> 
</xs:restriction> 
</xs: simpleType> 

<xs:simpleType name="TwoBitType"> 

<xs:restriction base="xs:string"> 
<xs :pattem value=" [0- 1 ] [0- 1 ] "/> 

</xs:restriction> 
</xs: simpleType> 

<xs:simpleType name="ThreeBitType"> 

<xs:restriction base="xs:string"> 

<xs :pattem value=" [0- 1 ] [0- 1 ] [0- 1 ] "/> 

</xs:restriction> 
</xs:simpleType> 

<xs:simpleType name="FourBitType"> 

<xs:restriction base="xs:string"> 

<xs :pattem value=" [0- 1 ] [0- 1 ] [0- 1 ] [0- 1 ] "/> 

</xs:restriction> 
</xs: simpleType> 

<xs:simpleType name="FiveBitType"> 

<xs:restriction base="xs:string"> 

<xs :pattem value=" [0- 1 ] [0- 1 ] [0- 1 ] [0- 1 ] [0- 1 ] "/> 

</xs:restriction> 
</xs:simpleType> 

<xs:simpleType name="SixBitType"> 

<xs:restriction base="xs:string"> 

<xs :pattem value=" [0- 1 ] [0- 1 ] [0- 1 ] [0- 1 ] [0- 1 ] [0- 1 ] "/> 

</xs:restriction> 
</xs:simpleType> 

<xs : simpleType name= "SevenBitType "> 

<xs:restriction base="xs:string"> 

<xs :pattem value=" [0- 1 ] [0- 1 ] [0- 1 ] [0- 1 ] [0- 1 ] [0- 1 ] [0- 1 ] "/> 

</xs:restriction> 
</xs: simpleType> 
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<! —Definition of complex types~> 
<! —Definition of BearerCapability Octets— > 
<xs:complexType name="BC0ctet3Type"> 
<xs:sequence> 

<xs:element name="CodingStandard" type="TwoBitType"/> 
<xs:element name="InfomiationTransferCabability" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="BC0ctet4Type"> 
<xs:sequence> 

<xs:element name="TransferMode" type="TwoBitType"/> 
<xs : element name= "InformationTransferRate" type= "FiveBitType "/> 
</xs:sequence> 
</xs:complexType> 

<x s : complexType name= " BC Octet4- 1 Type " > 
<xs:sequence> 

<xs:element name="RateMultiplier" type="SevenBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs : complexType name= "BCOctetSType "> 
<xs:sequence> 

<xs:element name="LayerlIdentification" type="TwoBitType"/> 
<xs:element name="UserInfoLayerlProtocol" type="FiveBitType"/> 
</xs:sequence> 
</x s : complexType> 

<x s : complexType name= " BC OctetS aType "> 
<xs:sequence> 

<xs:element name="SynchronousAsynchronous" type="OneBitType"/> 
<xs:element name=" Negotiation" type="OneBitType"/> 
<xs:element name="UserRate" type="FiveBitType"/> 
</xs:sequence> 
</x s : complexType> 

<xs: complexType name="BC0ctet5bVl 10Type"> 
<xs:sequence> 

<xs:element name='TntermediateRate" type="TwoBitType"/> 
<xs:element name="NIConTX" type="0neBitType7> 
<xs:element name="NIConRX" type="0neBitType7> 
<xs:element name="FlowControlOnTX" type="OneBitType"/> 
<xs:element name="FlowControlOnRX" type="OneBitType"/> 
</xs:sequence> 
</x s : complexType> 

<xs:complexType name="BCOctet5bV120Type"> 
<xs:sequence> 

<xs:element name="RateAdaptionHeader" type="OneBitType"/> 
<xs:element name="MultipleFrameEstablishmentSupport" type="OneBitType"/> 
<xs:element name="ModeOfOperation" type="OneBitType"/> 
<xs:element name="LogicalLinkIdentifier" type="OneBitType"/> 
<xs:element name="Assignor" type="OneBitType"/> 
<xs:element name='TnbandOutbandNegotiation" type="OneBitType"/> 
</xs:sequence> 
</xs : complexType> 
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<xs:complexType name="BC0ctet5cType"> 
<xs:sequence> 

<xs:element name="NumberOfStopBits" type="TwoBitType"/> 
<xs:element name="NumberOfDataBits" type="TwoBitType"/> 
<xs:element name="Parity" type="ThreeBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs:complexType name="BC0ctet5dType"> 
<xs:sequence> 

<xs:element name="DuplexMode" type="OneBitType"/> 
<xs:element name="ModemType" type="SixBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="BC0ctet6Type"> 
<xs:sequence> 

<xs:element name="Layer2Identification" type="TwoBitType"/> 
<xs:element name="UserInfoLayer2Protocol" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs : complexType name= "BCOctetTType "> 
<xs:sequence> 

<xs:element name="Layer3 Identification" type="TwoBitType"/> 
<xs:element name="UserInfoLayer3 Protocol" type="FiveBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<x s : complexType name= " BC OctetV aType "> 
<xs:sequence> 

<xs:element name="AdditionalLayer3Info" type="FourBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs: complexType name="BC0ctet7bType"> 
<xs:sequence> 

<xs:element name="AdditionalLayer3Info" type="FourBitType"/> 
</xs:sequence> 
</xs:complexType> 

<! —Definition of High Layer Compatibility Octets— > 
<xs:complexType name="HL0ctet3Type"> 
<xs:sequence> 

<xs:element name="CodingStandard" type="TwoBitType"/> 
<xs:element name=" Interpretation" type="ThreeBitType"/> 
<xs:element name="PresentationMethod" type="TwoBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="HL0ctet4Type"> 
<xs:sequence> 

<xs:element name="HighLayerCharacteristics" type="SevenBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs: complexType name="HL0ctet4aMaintenanceType"> 
<xs:sequence> 

<xs:element name="HighLayerCharacteristics" type="SevenBitType"/> 
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</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="HLOctet4aAudioType"> 
<xs:sequence> 

<xs:element name="VideoTelephonyCharacteristics" type="SevenBitType"/> 
</xs:sequence> 
</xs:complexType> 

<!— Definition of Low Layer Compatibility Octets~> 
<xs:complexType name="LL0ctet3Type"> 
<xs:sequence> 

<xs:element name="CodingStandard" type="TwoBitType"/> 
<xs:element name="InformationTransferCapability" type="FiveBitType"/> 
</xs:sequence> 
</xs:complexType> 

<x s : complexType name= "LLOctetS aType " > 
<xs:sequence> 

<xs:element name="NegotiationIndicator" type="OneBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs : complexType name= "LL0ctet4Type"> 
<xs:sequence> 

<xs:element name="TransferMode" t5^e="TwoBitType"/> 
<xs :element name= " InformationTransferRate" type= "FiveBitType "/> 
</xs:sequence> 
</x s : complexType> 

<xs : complexType name= "LL0ctet4- 1 Type"> 
<xs:sequence> 

<xs:element name="RateMultiplier" type="SevenBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs: complexType name="LL0ctet5Type"> 
<xs:sequence> 

<xs:element name="LayerlIdentification" type="TwoBitType"/> 
<xs:element name="UserInfoLayerlProtocol" type="FiveBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs : complexType name= "LLOctetS aType " > 
<xs:sequence> 

<xs:element name="SynchronousAsynchronous" type="OneBitType"/> 
<xs:element name=" Negotiation" type="OneBitType"/> 
<xs:element name="UserRate" type="FiveBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="LL0ctet5bVl 10Type"> 
<xs:sequence> 

<xs:element name='TntemiediateRate" type="TwoBitType"/> 
<xs:element name="NIConTX" type="OneBitType"/> 
<xs:element name="NIConRX" type="OneBitType"/> 
<xs:element name="FlowControlOnTX" type="OneBitType"/> 
<xs:element name="FlowControlOnRX" type="OneBitType"/> 
</xs:sequence> 
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</x s : complexTypo 

<xs:complexType name="LLOctet5bV120Type"> 
<xs:sequence> 

<xs:element name="RateAdaptionHeader" type="OneBitType"/> 
<xs:element name="MultipleFrameEstablishmentSupport" type="OneBitType"/> 
<xs:element name="ModeOfOperation" type="OneBitType"/> 
<xs:element name="LogicalLinkIdentifier" type="OneBitType"/> 
<xs:element name="Assignor" type="OneBitType"/> 
<xs:element name="InbandOutbandNegotiation" type="OneBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="LL0ctet5cType"> 
<xs:sequence> 

<xs:element name="NumberOfStopBits" type="TwoBitType"/> 
<xs:element name="NumberOfDataBits" type="TwoBitType"/> 
<xs:element name="Parity" type="ThreeBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="LL0ctet5dType"> 
<xs:sequence> 

<xs:element name="DuplexMode" type="OneBitType"/> 
<xs:element name="ModemType" type="SixBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="LL0ctet6Type"> 
<xs:sequence> 

<xs:element name="Layer2Identification" type="TwoBitType"/> 
<xs:element name="UserInfoLayer2Protocol" type="FiveBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs xomplexType name= "LL0ctet6aHDLCType "> 

<xs:sequence> 

<xs:element name="Mode" type="TwoBitType"/> 

</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="LL0ctet6aUserSpecificType"> 
<xs:sequence> 

<xs:element name="UserSpecificLayer2Information" type="SevenBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="LL0ctet6bType"> 
<xs:sequence> 

<xs:element name="WindowSize" type="SevenBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="LL0ctet7Type"> 
<xs:sequence> 

<xs:element name="Layer3 Identification" type="TwoBitType"/> 
<xs:element name="UserInfoLayer3 Protocol" type="FiveBitType"/> 
</xs:sequence> 
</xs : complexTypo 
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<xs:complexType name="LL0ctet7aUserSpecificType"> 
<xs:sequence> 

<xs:element name=" Op tionalLayerS Information" type="SevenBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<x s : complexType name= "LLOctetV aX25 Type " > 

<xs:sequence> 

<xs:element name="Mode" type="TwoBitType"/> 

</xs:sequence> 
</x s : complexTypo 

<xs: complexType name="LLOctet7bX25Type"> 
<xs:sequence> 

<xs:element name="DefaultPacketSize" type="FourBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="LL0ctet7cType"> 
<xs:sequence> 

<xs:element name="PacketWindowSize" type="SevenBitType"/> 
</xs:sequence> 
</xs:complexType> 

<xs: complexType name="LLOctet7aTR9577Type"> 
<xs:sequence> 

<xs:element name="AdditionalLayer3Info" type="FourBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs: complexType name="LLOctet7bTR9577Type"> 
<xs:sequence> 

<xs:element name="AdditionalLayer3Info" type="FourBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs : complexType name= "DispOctetSType "> 
<xs:sequence> 

<xs:element name="DisplayInformation" type="SevenBitType"/> 
</xs:sequence> 
</xs:complexType> 

<!~Definition of the information elements— > 

<xs:complexType name="BearerCapabilityType"> 
<xs:sequence> 

<xs:element name="BCoctet3" type="BCOctet3Type7> 
<xs:element name="BCoctet4" type="BC0ctet4Type"/> 
<xs:element name="BCoctet4-l" type="BC0ctet4-lType" minOccurs="0"/> 
<xs:element name="BCoctet5" type="BC0ctet5Type" minOccurs="0"/> 
<xs:element name="BCoctet5a" type="BC0ctet5aType" minOccurs="0"/> 
<xs:element name="BCoctet5bV110" type="BCOctet5bV110Type" minOccurs="0"/> 
<xs:element name="BCoctet5bV120" type="BCOctet5bV120Type" minOccurs="0"/> 
<xs:element name="BCoctet5c" type="BC0ctet5cType" minOccurs="0"/> 
<xs:element name="BCoctet5d" type="BC0ctet5dType" minOccurs="0"/> 
<xs:element name="BCoctet6" type="BC0ctet6Type" minOccurs="0"/> 
<xs:element name="BCoctet7" type="BC0ctet7Type" minOccurs="07> 
<xs:element name="BCoctet7a" type="BC0ctet7aType" minOccurs="07> 
<xs:element name="BCoctet7b" type="BC0ctet7bType" minOccurs="07> 
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</xs:sequence> 
</x s : complexTypo 

<x s : complexType name= " HighLayerCompatibilityType " > 
<xs:sequence> 

<xs:element name="HL0ctet3" type="HLOctet3Type7> 
<xs:element name="HL0ctet4" type="HL0ctet4Type"/> 

<xs:element name="HL0ctet4aMaintenance" type="HL0ctet4aMaintenanceType" 
minOccurs="07> 

<xs:element name="HL0ctet4 Audio" type="HLOctet4aAudioType" minOccurs="0"/> 
</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="LowLayerCompatibilityType"> 
<xs:sequence> 

<xs:element name="LL0ctet3" type="LLOctet3Type7> 
<xs:element name="LL0ctet3a" type="LL0ctet3aType" minOccurs="07> 
<xs:element name="LL0ctet4" type="LL0ctet4Type7> 
<xs:element name="LL0ctet4-l" type="LL0ctet4-lType" minOccurs="07> 
<xs:element name="LL0ctet5" type="LL0ctet5Type" minOccurs="07> 
<xs:element name="LL0ctet5a" type="LL0ctet5aType" minOccurs="07> 
<xs:element name="LLOctet5bV110" type="LLOctet5bV110Type" minOccurs="07> 
<xs:element name="LLOctet5bV120" type="LLOctet5bV120Type" minOccurs="07> 
<xs:element name="LL0ctet5c" type="LL0ctet5cType" minOccurs="07> 
<xs:element name="LL0ctet5d" type="LL0ctet5dType" minOccurs="07> 
<xs:element name="LL0ctet6" type="LL0ctet6Type" minOccurs="07> 
<xs:element name="LL0ctet6aHDLC" type="LL0ctet6aHDLCType" minOccurs="07> 
<xs:element name="LL0ctet6aUserSpecific" type="LL0ctet6aUserSpecificType" 
minOccurs="07> 

<xs:element name="LL0ctet6b" type="LL0ctet6bType" minOccurs="07> 
<xs:element name="LL0ctet7" type="LLOctet7Type7> 

<xs:element name="LL0ctet7aUserSpecific" type="LL0ctet7aUserSpecificType" 
minOccurs="0"/> 

<xs:element name="LLOctet7aX25" type="LLOctet7aX25Type" minOccurs="07> 
<xs:element name="LLOctet7bX25" type="LLOctet7bX25Type" minOccurs="07> 
<xs:element name="LL0ctet7c" type="LL0ctet7cType" minOccurs="07> 
<xs:element name="LLOctet7aTR9577" type="LLOctet7aTR9577Type" 
minOccurs="07> 

<xs : element name=" LLOctet7bTR9577 " type= "LLOctet7bTR9577Type " 
minOccurs="07> 

</xs:sequence> 
</x s : complexType> 

<xs:complexType name="DisplayType"> 
<xs:sequence> 

<xs:element name="DispOctet3" type="DispOctet3Type"/> 

</xs:sequence> 
</x s : complexType> 
<!— Definition of progress indicator— > 
<xs: complexType name="ProgressOctet3Type"> 

<xs:sequence> 

<xs:element name="CodingStandard" type="TwoBitType"/> 
<xs:element name="Location" type=" FourBitType "/> 
</xs:sequence> 
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</x s : complexTypo 

<xs:complexType name="ProgressOctet4Type"> 
<xs:sequence> 

<xs:element name="ProgressDescription" type="SevenBitType"/> 
</xs:sequence> 
</x s : complexTypo 

<xs:complexType name="ProgressIndicatorType"> 
<xs:sequence> 

<xs:element name="ProgressOctet3" type="ProgressOctet3Type"/> 
<xs:element name="ProgressOctet4" type="ProgressOctet4Type"/> 
</xs:sequence> 
</x s : complexTypo 
<!— Definition of document structure~> 
<xs:element name="PSTN-transit"> 
<xs : complexTypo 
<xs:sequence> 

<xs:element name="BearerInfomationElement" type="BearerCapabilityType" 
maxOccurs="2"/> 

<xs:element name="HighLayerCompatibility" type="HighLayerCompatibilityType" 
minOccurs="0" maxOccurs="2"/> 

<xs:element name="LowLayerCompatibility" type="LowLayerCompatibilityType" 
minOccurs="0"/> 

<xs:element name="ProgressIndicator" type="ProgressIndicatorType" minOccurs="0" 
maxOccurs="unbounded"/> 

<xs:element name="Display" type="DisplayType" minOccurs="0" 
maxOccurs="unbounded"/> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
</xs:schema> 
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